3 ms·
It's entirely valid for a client to set the CD bit and to perform its own DNSSEC validation, instead of relying on a recursive cache. It's not particularly com
by colmmacc 15y ago
It's entirely valid for a client to set the CD bit and to perform its own DNSSEC validation, instead of relying on a recursive cache.
It's not particularly common today, but it is the ultimate expression of DNSSEC.
Browsers have already moved far beyond the "gethostbyname()" [1] API, and typically implement their own stub resolvers with support for better round-robin load balancing, pre-fetching, and forward collapsing (permitting connection sharing between names that ultimately resolve to the same IP). There's no reason DNSSEC validation can't be part of a browser.
[1] So has almost everyone, getaddrinfo() is the more common equivalent call today.
- tptacek 15y agoI'm not suggesting that DNSSEC validation can't be part of a browser; I'm suggesting that it isn't part of a browser, or part of virtually any other computer program that uses the DNS. Tens of thousands of programs have been built to variants of the BSD socket interface, none of which automatically admit to DNSSEC. You could just as easily suggest that we'll all have IPv6 support, just as soon as every piece of software that assumes an IP address is 4 bytes long gets updated. But it's actually worse than IPv6, because all IPv6 does (as far as a socket program is concerned) is make IP addresses bigger. DNSSEC requires the application to implement a new state machine to handle the case where validation of a name fails, and implement the UI to handle the user's input to that state machine. Also, I object to the notion that end-system DNSSEC validation is "the ultimate expression of DNSSEC". No; the IETF spent years trying to standardize alternatives to end-systems doing DNSSEC (like TSIG), and many of the same standards people objected to the idea of end-systems implementing full recursive resolvers (load on the roots, etc). It's only when the "last mile" of DNSSEC comes under scrutiny that they suddenly decide we should all be running full caches after all. (gethostbyname, getaddrinfo, same problem; like I said, you might just as productively offer failure/alternative information over HTTP REST, because getting that information into real-world programs requires significant code changes no matter what).
- colmmacc 15y agoDNSSEC validation is part of chrome; http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html DNSSEC is about end-to-end authenticity for DNS data, and one of those ends is the user application, so it's understandable that a burden of responsibility would shift towards it. TSIG is about transport security, it's not about data authenticity, I wouldn't describe it as an alternative - it is complementary to DNSSEC. If DNSSEC succeeds, then doubtless there will be some successful in-application libraries and APIs for performing this - and those state machines won't be something we all have to worry about. But yes, it does shift the work-load.
- tptacek 15y agoNo, a single feature that exploits DNSSEC validation is part of Chrome. Securing DNS with "end-to-end authenticity for DNS data" is like securing the web by signing every individual web page.
- danyork 15y agoPlugins/extensions are available now for both Chrome and Firefox that provide a visual indicator in the address bar: http://www.internetsociety.org/deploy360/resources/how-to-add-dnssec-support-to-google-chrome/ http://www.internetsociety.org/deploy360/resources/how-to-ad... http://www.internetsociety.org/deploy360/resources/how-to-add-dnssec-support-to-mozilla-firefox/ http://www.internetsociety.org/deploy360/resources/how-to-ad... But, to your point, these are not built-in and require a user to actually install the extensions. And of course, a user can ignore the key icon (as some ignore the lock-in and SSL/TLS popups).