Slashdot Mirror

← Back to Stories (view on slashdot.org)

DNSSEC: Good Enough?

Posted by timothy on from the those-darn-numbers dept.

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

4 of 188 comments (clear)

  1. Check out Internet Mail 2000 by Bryan+Ischo · · Score: 5, Informative

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

  2. dan bernstein's position on this by tmu · · Score: 5, Informative
    People interested in this issue should see dan bernstein's position on the issue of DNSSEC.

    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.

  3. Ripe Training For DNSSEC by thriemus · · Score: 5, Informative

    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
  4. Re:Security Issues? by mellon · · Score: 5, Informative

    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... :'}