The "clients" in DNSSEC are stub resolvers that just speak normal DNS. The deployment model for the protocol is that end stations don't even know DNSSEC exists. They're just programs calling "gethostbyname()". You could "allow for" anything from a bit in the DNS header to an HTTP REST web service to provide information about DNSSEC failures, but what does that matter to the millions and millions of lines of software that are built on the assumption that DNS either (a) works or (b) doesn't?

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 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.

I'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).

DNSSEC validation is part of chrome;

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.

No, 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.

Plugins/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-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).

So perhaps the larger question is - when will the DNS stub resolvers in the various operating systems get updated to be DNSSEC-aware so that applications could make a request for the DNSSEC information and make those decisions themselves?