Comcast DNSSEC Goes Live 165
An anonymous reader writes "In a blog post, Comcast's Jason Livingood has announced that Comcast has signed all of its (5000+) domains in addition to having all of its customers using DNSSEC-validating resolvers. He adds, 'Now that nearly 20 million households in the U.S. are able to use DNSSEC, we feel it is an important time to urge major domain owners, especially commerce and banking-related sites, to begin signing their domain names.'"
Re:SOPA and DNSSEC? (Score:5, Informative)
I guess I'm not sure how SOPA and DNSSEC overlap, could someone explain it in a couple of sentences? Does DNSSEC hinder or help? I would assume hinder SOPA... I'm going to research more, but was hoping to get a quick brief from someone knowledged...
Well, let's try a car analogy. Before DNSSEC, anyone could put up a road sign, and you'd have no way of knowing whether it would send you the right way or not. There were a few publicized cases of cars going down the wrong road, a few pileups, but most people got to/from work everyday.
However, some very smart people were worried some other smart people could swap the road signs. So they added smaller digital tags on the back of the signs that had a special number encoded in it and the name of the municipality that placed the sign there. You need a special box to tell you what it says. Not many people were keen on spending the money to impliment this, since the only people that could read the special codes were police, firefighters, and some guys riding around in black SUVs. For the majority of drivers, nothing changed.
Separately, these municipalities were threatened with lawsuits by very large companies and the government if they allowed signs to stay up on roads they didn't like, or went to places they didn't like... So they've been busy tearing down signage all over the place to appease these well-monied interests. Sometimes the signs being taken down have the little tags, but most of the time they don't. Drivers that are familiar with the area won't have a problem because they know the address and route already, but younger, and inexperienced drivers might not, and for them, these new laws could keep them from getting to those places.
Re:Comcast supports SOPA (Score:4, Informative)
Re:Just in time (Score:3, Informative)
There. DNSSEC has a point now with SOPA. :)
Re:How about going back to flat-rate data? (Score:4, Informative)
I know I'm a heavy user, but 700+GB a month is not unusual for me and many months I've exceeded 1TB. 250GB is a good cap for an entry-level plan, but it's hilariously low when DOCSIS 3 speeds are in play.
What do you download that exceeds 700+GB? That's 25GB/day, which seems like an awful lot of data.
My household watches several hours of Netflix a day (we have no cable TV and watch Netflix streaming TV shows & movies), and as far as I know, we've never hit our Comcast cap.
Re:How about going back to flat-rate data? (Score:3, Informative)
Nope (Score:4, Informative)
In the case of registries outside of US jurisdiction, SOPA requires all ISPs within the US to filter domain name requests for allegedly infringing sites, when ordered by the US Attorney General.
Re:And how can I use it on my BIND server? (Score:5, Informative)
http://www.imperialviolet.org/2011/06/16/dnssecchrome.html [imperialviolet.org]
Re:And how can I use it on my BIND server? (Score:4, Informative)
There is no need to buy a certificate. DNSSEC does not use X.509 certificates. You generate your own keys and provide them to your registrar to be published upstream.
ISC has recently added "auto DNSSEC signing" to BIND, which may be the easiest way for most folks to add DNSSEC. This page has some information:
http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing
Here's a post with more info:
http://netlinxinc.com/netlinx-blog/45-dns/133-bind-970-part-4-automatic-zone-signing.html
Re:And how can I use it on my BIND server? (Score:5, Informative)
You can fairly easily sign your zones using Bind: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#DNSSEC [bind9.net]
This takes a few steps:
* Generate keys - a zone-signing key (ZSK) and a key-signing-key (KSK) - usually a pair of keys for each zone
* Sign your zones - well, the records inside them
* Now use your zone.signed file as the zonefile that Bind serves up
Next, once you query your server and everything looks good, you need to ship either the DNSKEY record or DS (digest of the key) to your registrar *. They will ship that to the registry, which signs either your key or digest. Most gTLDs (.com/.org) require only DS records, while ccTLDs (.de/.eu) require DNSKEY records.
Then, as long as you're using a DNSSEC aware resolver, you can test the hierarchy of the signed zone:
dig @149.20.64.21 comcast.com any +dnssec
Look for the "ad" bit set in the Flags section. If you just want to see the keys in this example, simply limit dig to that RR type:
dig @149.20.64.21 comcast.com dnskey +multiline +dnssec
DNSKEY 257 is the key-signing-key, which was sent to the registry, while DNSKEY 256 is the zone-signing key. Dig +trace to see the DS records at the .com registry - they host two different digests for the same key tag/id (35356):
dig comcast.com dnskey +multiline +dnssec +trace
You'll often notice zones with multiple keys - you must support more than one key at a time to enable key rotation. E.g. You, as an authoritative server operator, may wish to rotate your zone-signing key fairly often, while you may wish to rotate the key-signing-key once per year. Each registry decides the expiration of the key or digest they are storing.
* = Not all registrars support DNSSEC; once you sign your domain you cannot transfer the domain to a non-DNSSEC enabled registrar. Either you have to un-sign it or transfer it somewhere else.
There is no certificate authority involved, as the DNS hierarchy contains the signature chain, from the root servers, to each TLD, to each domain. One proposed use of DNSSEC is to publish an SSL certificate public key -- then no Certificate Authorities are required! A browser can use the DNSSEC validated response to match the public key (or more likely, fingerprint) to the web server it is connecting with. You can already use DNS to publish SSH key fingerprints [ietf.org], now you can sign that record for even more trust.
Re:SOPA and DNSSEC? (Score:5, Informative)
It's not about disabling DNSSEC. DNSSEC allows a resolver (your machine) to verify that the DNS answers it gets (from a cache, an ISP server, or wherever) are authentic records from the DNS hierarchy. Without DNSSEC you just accept whatever you're told on trust. Your ISP, or some script kiddie in Poland, can fuck with the answers and your first clue will be when TPB is just a blank page saying piracy is illegal or call Czeslaw for a good time.
The point is that DNSSEC will still tell the truth even when the government requires your ISP to lie to you. If you ask "Where is TPB?" under DNSSEC the only possible answers are "Here is the true authentic address for TPB" or "Error, someone is fucking with your DNS resolution". The US government would love the answer to be "Here is a US government web site reminding you that you are the property of Corporate America and subject to its whims" but DNSSEC rules that out. For US registries (like com) the US government can just go tell the registry operator to do what it says or go to jail. But to change the answers to the questions in non-US registries the most obvious option US government has is to put a bunch of men with guns on a helicopter, fly into another country and go break down the doors of the relevant DNS registry and insist they change the authentic records so that DNSSEC checks out OK.
Now I'm sure in the heads of the average 60-something senator voting for these measures that sounds proportionate. It's terrorists, or something, right? We're fighting a war here - the blood of patriots must flow and so on. But when you explain to a Navy seal that he's to go risk his neck so some fucker in a Hollywood corner office can afford to buy an extra yacht, that's going to stick.
Nobody is going to give that order. So if you have DNSSEC, the results of SOPA will be that you see errors every time you hit a page the government is censoring. Consider it your daily reminder that the US government works for the guy with the deepest pockets.
Re:Just in time (Score:5, Informative)
Re:How about going back to flat-rate data? (Score:2, Informative)
Re:And how can I use it on my BIND server? (Score:4, Informative)
Signing you own zone is trivial and you don't need to pay anyone. I even created a simple, short video on the subject using the DNSSEC-Tools components: http://www.youtube.com/watch?v=7ksgTFxAg6U [youtube.com]
Though I'm associated with the above project, I actually don't care what tool set you use: just sign your zone!
Re:How about going back to flat-rate data? (Score:4, Informative)
exposes such attacks for what they are.
It certainly does that, but it still breaks DNSSEC because it makes users expect DNSSEC failures under normal operation, which enables fraud because users will subsequently ignore future warnings. It further prevents client software developers from implementing countermeasures that would thwart a man in the middle attack since doing so would succeed just as well in bypassing the DNS blocking.
For example, client software might be designed so that if a DNSSEC failure occurs, the client first tries all configured DNS servers to try to get a valid response. If any of the servers is outside the country, the blocking fails. If not, the client software might then try to act as its own recursive DNS server. (Clients are normally not supposed to do this because it would put extra load on the authoritative DNS servers, but clients are normally not supposed to encounter DNSSEC failures, and doing it only in that rare circumstance would almost certainly not cause serious performance issues.) If the authoritative DNS server is outside the country (which it would be for a 'rogue site') then the blocking fails.
So either the law prohibits client software from being designed that way and the security benefits of DNSSEC are destroyed, or client software is designed to thwart a man in the middle attack and the law is a dead letter because the operators of intermediary DNS servers cannot prevent end users from receiving a true DNS response since an attempt to do so will only cause the client's DNSSEC implementation to detect and bypass the intermediary DNS server.