

Comcast Explains Why NASA's Web Site Was Blocked Last Week (DNSSEC) - danyork
http://www.internetsociety.org/deploy360/blog/2012/01/comcast-releases-detailed-analysis-of-nasa-gov-dnssec-validation-failure/

======
tptacek
Gee, it's not like you can search for [tptacek dnssec] in the search bar down
there and see me howling at the moon for years about how likely this stuff is
to happen.

([http://www.hnsearch.com/search#request/comments&q=tptace...](http://www.hnsearch.com/search#request/comments&q=tptacek+dnssec&sortby=create_ts+desc))

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.

~~~
tbrownaw
Doesn't DNSSEC allow for a way for the client to request results-plus-
validation-details instead of just results-if-valid?

~~~
tptacek
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.)_

~~~
colmmacc
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
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).

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

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

~~~
danyork
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-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/)

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

------
seppler
We validate DNSSEC and Comcast still hasn't fixed their own issues with
sz0071.ev.mail.comcast.net

------
smackfu
I wonder when the Google bot will start to respect DNSSEC?

~~~
sp332
Probably when Google's DNS servers do. 8.8.8.8 and 8.8.4.4

~~~
danyork
Google states here: <http://code.google.com/speed/public-dns/faq.html#dnssec>

"Does Google Public DNS support the DNSSEC protocol?

Google Public DNS supports EDNS0 extensions, which means that we accept and
forward DNSSEC-formatted messages; however, we do not yet validate responses."

------
joering2
still doesnt work from NYC.

~~~
sp332
I checked it with <http://dns.comcast.net/dig-tool.php> and it looks like
every Comcast DNS server gives a valid response. Is there another caching DNS
server between you and 75.75.75.75?

