What's funny is that this is a debate we had 2 years ago, you & I, where I said "DNSSEC will cause sites to disappear from the Internet because clients don't actually speak DNSSEC, caches do it on their behalf", and you said "but Cricket Liu wrote a blog post on how clients can use the CD and AD bits to do their own DNSSEC"† --- and here we are commenting on a story about how NASA disappeared from the Internet (for Comcast DNSSEC clients) and we're still acting like this is a debatable point.
It's not. It's obvious from the architecture of the system: either we forklift out all the code written to the original DNS service model (ie, all the code that does DNS everywhere), or we accept that DNSSEC will cause total site outages in every case where TLS causes popups.
† (This itself kind of a silly point, right, because you could also just install a full DNSSEC cache on every host on the Internet and claim that as the answer to this problem.)
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.
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).
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.
Securing DNS with "end-to-end authenticity for DNS data" is like securing the web by signing every individual web page.
http://www.internetsociety.org/deploy360/resources/how-to-ad...
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).
We can fix the most glaring problem with HTTPS/TLS in userland code by building things like Moxie Marlinspike's Convergence scheme; instead of allowing browser vendors and huge companies like Verisign to entirely own the decision of whose certificates are to be trusted, instead allow interested parties to create and share their own trust policies.
This does not actually change any part of the HTTPS/TLS protocol. The CA certificate validation of TLS is out-of-band; it works based on decisions made by browser vendors.
In the post-Moxie world, my mom doesn't decide whether RapidSSL is a trustworthy verifier for MAIL.GOOGLE.COM; instead, her system is simply configured to rely on a trust community --- perhaps run by volunteers for EFF, or by Google, or someone else.
DNSSEC is brittle and does not allow for this level of expressiveness. Under DNSSEC, in 2010, Ghadafi controls all names under .LY, full stop. You can't implement "trust agility" to get around it: that static brittle trust model is baked into the core of the Internet.
That's a bad thing.
(http://www.hnsearch.com/search#request/comments&q=tptace...)
When an SSL certificate fails to validate, your browser is prepared to kick off a whole UI state machine to allow you to decide whether to visit the site or not. That's because HTTP, at least as used by browsers, is an application-layer protocol.
DNS is an infrastructure protocol. It's like a dial tone; it's there or it isn't. Programs are built on the assumption that if DNS isn't working, either the site doesn't exist, or your Internet connection is misconfigured.
Protocols like DNSSEC work on the faulty assumption that trust is a binary thing; either a site's name is good or it isn't. In fact, trust is the product of a series of policy decisions. It's something that needs to be expressed at the application layer. DNS is simply the wrong place to host security policy.