On May 30, 2013, at 8:41 AM, Ben Laurie <[email protected]> wrote: >>> a) It introduces latency, and >> >> Negligible because DNS RRs are cached near the client, ideally at >> 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, >> mobile phone, ...), thereby eliminating issues wrt. MITM attacks >> between the client and the caching resolver. > > Even if this were true, first hit latency matters, too. As anecdotal > evidence, I just resolved a name unlikely to be cached locally: > > $ dig www.disney.com > ;; Query time: 535 msec > > Unacceptable.
Except that, thanks to glue records and parallelism and speculative prefetch, you can ALSO fetch TYPE=DANE along with the TYPE=A and TYPE=AAAA records that are already having to be fetched, and the DNSSEC related records (DS, DNSKEY, etc) can also be speculatively fetched, so there should be NO latency hit for fetching the records, with the only latency hit involving signature validation. Although I disagree about the cache local. The VALIDATION should be local, but it should still use the ISP-level recursive resolver cache, as that IS a huge win in practical performance and, thanks to DNSSEC in general, you don't have to trust that lying, MitMing SOB. >> Also with a DNSSEC-validating cache, the client does not need to >> repeatedly re-validate the same data. > > Our experiments suggest that a _large_ percentage of clients cannot > see DNSSEC records at all. This is the bigger problem, and I agree. We should have some detailed data soon from Netalyzr, the tests that have been running for a while are: Direct to the Internet fetching of DNSSEC records (DNSSEC to all roots for DS, DNSKEY, RRSIG, and NSEC, DNSSEC to .com for NSEC3) Recursive resolver fetching of DNSSEC records using DO Recursive resolver fetching of DNSSEC records without using DO to see if you can get the full necessary RRSIG for .com (e.g. OpenDNS fails the latter: If you query without DNSSEC, you don't get the RRSIG for the DS record for .com! But then again, OpenDNS is vocal that DNSSEC runs counter to their business model, so they will never support it) I suspect that a non-trivial (>.1%, probably >1%) of sessions will fail all three tests, but I haven't conducted that data analysis yet. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
