5 ms·

Comcast Explains Why NASA's Web Site Was Blocked Last Week (DNSSEC)

54 points by danyork 15y ago

joering2 15y ago
still doesnt work from NYC.
- sp332 15y ago
  I checked it with http://dns.comcast.net/dig-tool.php 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?
- danyork 15y ago
  Are you a Comcast subscriber in NYC? The issue only affected people who use Comcast as their ISP.
smackfu 15y ago
I wonder when the Google bot will start to respect DNSSEC?
- sp332 15y ago
  Probably when Google's DNS servers do. 8.8.8.8 and 8.8.4.4
  - danyork 15y ago
    Google states here: http://code.google.com/speed/public-dns/faq.html#dnssec 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."
tptacek 15y ago
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=tptacek+dnssec&sortby=create_ts+desc 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.
- tbrownaw 15y ago
  Doesn't DNSSEC allow for a way for the client to request results-plus-validation-details instead of just results-if-valid?
  - tptacek 15y ago
    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.)
seppler 15y ago
We validate DNSSEC and Comcast still hasn't fixed their own issues with sz0071.ev.mail.comcast.net

54 points by danyork 15y ago

joering2 15y ago

still doesnt work from NYC.

sp332 15y ago
I checked it with http://dns.comcast.net/dig-tool.php 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?
danyork 15y ago
Are you a Comcast subscriber in NYC? The issue only affected people who use Comcast as their ISP.

smackfu 15y ago

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

sp332 15y ago
Probably when Google's DNS servers do. 8.8.8.8 and 8.8.4.4
- danyork 15y ago
  Google states here: http://code.google.com/speed/public-dns/faq.html#dnssec 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."

tptacek 15y ago

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=tptacek+dnssec&sortby=create_ts+desc 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.

tbrownaw 15y ago
Doesn't DNSSEC allow for a way for the client to request results-plus-validation-details instead of just results-if-valid?
- tptacek 15y ago
  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.)

seppler 15y ago

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