Slashdot Mirror
DNSSEC: Good Enough?
Phil Windley writes "DNS Security Extension, or DNSSEC, is a set of extensions to DNS, which provide end-to-end authenticity and integrity. Paul Mockapetris, the inventor of DNS believes DNSSEC is the answer to many of the identity problems on the Internet. He wants the IETF to get off the dime and approve the DNSSEC spec. A recent article in ZDNet TechUpdate interviews Mockapertis on DNSSEC (summary)."
D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:
...
http://cr.yp.to/im2000.html
The basic premise is this:
"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."
It's an interesting concept and worth a read.
Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.
Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email
The summary: It's unfinished, the BIND company has poor implementations (like most everything else it implements), and won't provide a real increase in security. Interesting stuff.
It seems RIPE have a One Day Introduction Course for "DNSSEC and related tools, and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zone"
- Sig
Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.
You can find it at IRIS
I don't understand the security issues here? I tried reading the FAQ but I'm a mumbling nincompoop. Can someone explain in a bit better detail about why we needsecurity for DNS? Is there any actual recorded instances of people breaking into the DNS database? Is this the website hacking I've heard about?
:'}
DNS is mostly a UDP-based protocol, and it's pretty easy to spoof. When you type "www.ibm.com" in your browser, a UDP packet goes from your computer to a caching name server at your ISP (I'm oversimplifying here, BTW, but if you aren't a DNS geek this is most likely exactly what happens). The resolving name server sends another UDP packet out to the root name server to find out who to ask about "ibm.com". Then the root name server says "go talk to ibmns1.ibm.com at 10.1.17.2". Then the caching name server talks to 10.1.17.2 and asks it to resolve "www.ibm.com". Then it sends a UDP packet back to your computer telling it the IP address for www.ibm.com.
Notice that all of these UDP packets went over the network in the clear, and you can see that there were quite a number of opportunities to spoof you. If I can do a root hack on the machine that's running your ISP's caching name server, for example, I can give you a bogus IP address for www.ibm.com, and then steal your credit card info when you try to buy something there. If I can watch your packets and respond faster than the caching name server does, I can also convince you to go to the wrong place. So it's not an insignificant vulnerability.
With HTTP, if you are smart, you check to make sure that your web browser is doing a secure transaction, but frankly, most people just ignore this issue, or don't even know what it means.
With DNSSEC, your resolver on your computer knows the public half of the root DNSSEC key. So it can verify the answer it gets, all the way from the top down to the bottom. If someone spoofs the response, the resolver ignores the spoofed packet, and you get the real one. If your ISP's caching name server is compromised, you can't look up www.ibm.com, and eventually you call your ISP and complain. They fix their nameserver, and you go back to your business, unspoofed.
As I said in a previous comment, DNSSEC is also a handy place to stash keys, precisely because you can validate them as I've described.
And, BTW, I glossed over a lot of details here. If you really want to know how this stuff works, you should probably read the RFCs...
There are certain aspects of DNSSEC that are infrequently discussed.
.com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.
First is that DNSSEC adds a degree of rigidity and inter-dependency to the net that makes it more brittle in the face of a natural or intentional disaster. When things have fallen apart, the time to recover is greatly increased if the rebuilders have to rebuild the security hierarchy before names can start resolving.
Another aspect is that DNSSEC tends to wire-in a single DNS root and wire-out competing roots.
Now, a lot of people think that competing roots are a horrible thing. And a lot of other people think they are a great thing. (I've been using competing roots for years with zero problems, so you can guess which camp I'm in.) And some communities (AOL) and countries, are not necessarily making noises that they really like the idea of one god-like root for DNS. (They want consistency, their concern is about there being a single authority.) Competing roots are also advocated as a way to escape captured regulatory bodies, such as ICANN.
For some of the big zones -
If you think DNSSEC is vapourware, your information is outdated. As I presented in various talks this year at BlackHat, DefCon and CCC this year, DNSSEC is ready to be deployed, and IS deployed.
We are currently running over 150 domains in DNSSEC, using bind9 and some perl tools written by RIPE. We are using this to accomplish IPsec Opportunistic Encryption, which means massive deployment of IPsec tunnels by using secured DNS information for key material.
Please see:
DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?