On Fri, Sep 06, 2013 at 09:12:08AM -0700, Ian Fette (????????) wrote:
> That would assume deploying dnssec on Gmail.com is somehow easier than on
> Google.com :-)
Sorry if I was unclear. My example was about testing TLSA in a
signed zone on non-production TLS endpoints before publishing for
the first time on production endpoints. No intent to imply that
any particular domain is an easier place to do DNSSEC.
In the specific case of gmail.com, you'd need DNSSEC on both gmail.com
and google.com:
$ dig +short -t mx gmail.com | sort -n
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
since not only the gmail.com MX RRset needs to be secure, but also
the zone containing the actual MX hosts, since these are the TLSA
base domains.
I am guessing that one the major obstacles to DNSSEC for Google is
all the interaction with DNS geo load-balancing gear. I don't know
whether there is gear of that ilk that supports DNSSEC, or whether
beyond the hardware there are architectural obstacles to DNSSEC in
combination with highly dynamic DNS responses.
It may take some time for Google to publish TLSA RRs in a signed
zone, but it is I hope worth the effort to figure out what the
obstacles are and what it would take to address them.
In the mean time Google can easily add client-side DANE TLSA support,
this just requires a DNSSEC aware resolver.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
