Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Kaminsky On DNS Bugs a Year Later and DNSSEC 127

L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."
This discussion has been archived. No new comments can be posted.

Kaminsky On DNS Bugs a Year Later and DNSSEC

Comments Filter:
  • by mtremsal ( 1554627 ) on Thursday June 25, 2009 @11:13AM (#28466687)

    Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.

    • .. hit yet.

      Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.

      Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.

      • by DNS-and-BIND ( 461968 ) on Thursday June 25, 2009 @03:40PM (#28470739) Homepage
        Q: Why is starting a comment in the Subject: line incredibly annoying?
        • by brunes69 ( 86786 )

          If /. didn't have this inane length limit on the size of a comment tile that dates back to the silent era, I would not have to do that.

      • Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.

        Not only that, but if you invest and it actually works, you get the impression you wasted money, because nothing happens. :P

        It's the same thing with Global Climate Change. If we actually fight it tooth and nail, the best we can hope for is no change from the present. Hardly a reward! ;)

    • Re: (Score:3, Interesting)

      by askksa ( 1167121 )
      There are numerous issues with implementing DNSSEC. The idea has been around for like 14 years now. Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.
      • Re:Optimistic guy (Score:5, Informative)

        by Effugas ( 2378 ) * on Thursday June 25, 2009 @11:32AM (#28466903) Homepage

        (This is Dan)

        DNSCurve can't achieve end-to-end security while still caching. Without the former, you're trusting the name server at Starbucks not to be malicious. Without the latter, there's a 10x (minimum) increase in DNS traffic and the internet collapses.

        There's some really interesting math going on, but operationally DNScurve isn't a good path.

        That being said, there are some really interesting things from DNScurve we can integrate into DNSsec without any code mods. Key rollover is a mess in DNSSEC, and it's somewhat unnecessary.

        • Re: (Score:3, Interesting)

          by foom ( 29095 )
          I'm just going to repost my last comment on this subject. I don't think things have changed since then, but if they have I'd certainly be interested to know. :)

          You might be interested in this thread:
          where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. Th

          • Re: (Score:3, Interesting)

            by Effugas ( 2378 ) *

            (This is Dan)

            That's interesting if you're just trying to secure DNS. We have much bigger fish to fry -- fish that require us not trusting the NS at Starbucks.

            • by foom ( 29095 )


              DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).

              DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.

              You're screwed either way.

              Or, you can decide to either use a different resolver somewhere on the interne

              • Re: (Score:3, Interesting)

                by Effugas ( 2378 ) *

                (This is Dan)

                Hehe. OK, I like you foom. Lets talk.

                So the deal is, DNSSEC lets the server at Starbucks cache DNSSEC records for you. So even if it's not doing the validation, it can at least remember the crypto such that each backend host that is doing validation can enjoy the cached records on the shared NS.

                You can't do that with DNScurve, since the crypto is link based.

                I've been playing with the Curve25519 code lately. It's cool, I have use for it (understatement), and it's a joy to work with. But DNS

                • DNSSEC has two big problems:

                  1. Without an unbroken chain of trust to the root, it's worthless. Self signed DNSSEC is no better than no DNSSEC.
                  2. It's vulnerable to MITM attacks - just strip the DNSSEC information from the returned packets and return a normal (modified) DNS reply.
                  3. Because of the chain of trust setting it up will cost $$$ - probably going to Verisign, as usual.
                  4. Until absolutely everyone in the world uses DNSSEC the fallback to normal DNS cannot be removed, so 2. remains a problem. 3. gu

                  • Oh and I'd add the thing is *hideously* complex to setup, with multiple competing implementations that aren't compatible with each other because some have special DNS tags, some use TXT records, the formats keep changing, etc. Spent 4 days on it once.. I got maybe 10% of the available dnssec testers to even recognize that I implemented their brand of dnssec.

                    • by Effugas ( 2378 ) *

                      (This is Dan)

                      1) Agreed. I'm not very popular in some DNSSEC circles because of it :) But yes, the entire Trust Anchor Repository thing is a mess. That's why it's so important to get the root signed.
                      2) With the root signed, you always have a trusted path that says if a given domain has DNSSEC or not. If it does, stripping the DNSSEC won't matter, you'll know there's *supposed* to be signatures there.
                      3) Because DNSSEC delegates, it's not really amenable to the sort of tricks that have cost money in the pa

                • by foom ( 29095 )

                  A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.

                  Now it's basically a caching recursive resolver.

                  So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authori

                  • by Effugas ( 2378 ) *

                    (This is Dan)

                    Estimates on cache hit rates in DNS are about 90% -- meaning for every query that hits a server, ten queries got chomped in a cache.

                    I'm uncomfortable asking the Internet to increase their DNS query capacity by 10x. DNS has a performance curve where once it dies, it dies kind of catastrophically. 10x increases are asking for trouble.

                    • by Effugas ( 2378 ) *

                      ...not to mention that DNSCurve requires per-query crypto on the server, while DNSSEC does not (by a design that really, really wants to allow offline key signing). Curve25519 is fast but it's not *that* fast.

                    • by foom ( 29095 )

                      Your statistic would be valid for no cache vs a cache.

                      But that's not the actual question at hand.

                      The question is:
                      What's the cache hit rate for a recursive cache serving a group of machines, vs. the cache hit rate for a recursive cache serving just a single machine.

                      I'm going to place my bet on nowhere near a 10x increase in traffic from having an unshared local cache.

                      But I haven't done the test. If anyone wants to (or knows of literature that's already explored this)...

                    • by foom ( 29095 )

                      See here [], about crypto CPU usage.

                      I'll also note that DNSCurve lookups use less network bandwidth than DNSSEC. DNSSEC drastically increases network bandwidth requirements with all those individual record signatures that need to be returned...

                    • by Effugas ( 2378 ) *

                      (This is Dan)

                      The point is that we can actually share DNSSEC responses across multiple nodes, not just a single node, using the existing framework. Yes, we will need clients that *can* go straight to the root. But they won't *have* to, which is a neat design element of DNSSEC.

                      Keep hitting me here though, maybe we can find a problem!

                    • by Effugas ( 2378 ) *

                      (This is Dan)

                      It is true that DNSSEC increases aggregate bandwidth.

                      I'm not sure about the DNSCurve numbers right now, given that the implementation I've seen can only do about 5,000 encrypt/decrypts a second on hardware that'll do 15,000 DNS responses a second.

          • The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.

      I guess it depends if you care about getting the correct IP address back when resolving a host or not.

      Personally, when i type into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.

      To each their own thou!

      • Personally, when i type into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.

        See, it's boring people like you who take the fun out of web surfing. Down with DNSSEC!

    • by jafiwam ( 310805 )
      Hey, if there is enthusiasm, there must be a good idea!

      Just look at Mr. Moller and his wonderful new car!
  • Need DNSSEC tools (Score:3, Interesting)

    by snsh ( 968808 ) on Thursday June 25, 2009 @11:47AM (#28467089)
    I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:

    1) implement BIND and do the key management and rotation from the command line
    2) spend $10,000 or so for an appliance from secure64 or nixu
    3) spend $1k/month for a hosted DNS provider like neustar or verisign
    4) install Win2008R2 RC and use it in producition

    I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.
  • by Ex-Linux-Fanboy ( 1311235 ) on Thursday June 25, 2009 @12:09PM (#28467417) Homepage Journal

    OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.

    Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS [], a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver []. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug [] (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:

    How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?

    I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.

    What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?

    • Re: (Score:1, Flamebait)

      by BitZtream ( 692029 )

      Considering you can't be bothered to read the information out there to even understand it, I think you'll find it very hard.

      Its not actually hard if you use someone elses encryption libraries, but if you are too lazy to even lookup how it works, and its fairly clear you have no understanding of how it works, its probably safe to say you are going to consider it hard.

      In reality, its not really a any worse than say adding SSL support to a web browser.

      • by foom ( 29095 )
        36 RFCs [] over the course of 12 years for a not-even-deployed-yet standard really is quite excessive. I don't blame him for thinking it's going to be a monster...
      • And, since you're too lazy to post links to DNSSEC howtos (like this one []), you're not helping and only name calling. The issue is that there are 15 RFCs with DNSSEC in the title [] and no clear idea where to get started.

        But, hey, this is Slashdot, where any idiot can get a lame name like "BitZream", and post insult anonymously.

        No worries; I will email Dan and talk to him offline about it.

    • Re: (Score:3, Interesting)

      by Effugas ( 2378 ) *

      (This is Dan)

      Heh Sam,

            It's a bit tricky, but we can work with you on the trickiness. DNSSEC is *much* easier to implement if you drop the somewhat unnecessary requirement for offline key signing, which is why BIND is so messy. Libunbound/ldns is flexible enough so you can integrate it, otherwise we can help you with the various wonkiness. Email me offline, ?

      • Hey, Dan, I just sent you an email offline from my gmail account. If you didn't get the email (if it somehow got eaten by a spam filter or what not), post a follow-up here. Thanks!
      • by Anonymous Coward

        I was very pleased to see this discussion taking place in an open forum, and would loved to have had the opportunity to follow it. I regret you've taken your interaction offline.

        I myself have been a DNS administrator (among other things) since the original implementation. I remember converting from host tables wasn't particularly fun at the time.

  • Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't :)
    Yeah, I know its a very common acronym.

  • The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain. If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter. For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not
    • by Effugas ( 2378 ) * on Thursday June 25, 2009 @12:30PM (#28467739) Homepage

      (This is Dan)

      Too many exceptions, like's low TTL, or CNN's non-response to nonexistent names, etc.

    • by Sancho ( 17056 ) *

      It's a matter of the scope of the attack. Any resolver (including your ISP's caching nameserver) can be the target. It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests. Second, your payoff is small--you got one machine to think that resolves to your IP address.

      The real target is any caching server that lots of people use. It's much easier to get these to make requests for lots of subd

  • by Anonymous Coward

    Hi Dan,

    Stupid question: can whoever holds the root key forge requests from all domains?

    e.g. if I am the US government, can I spoof an .ir domain?


    • Yes. But the us govt could do that before. DNSSEC doesn't enable this.

      DNSSEC only enables a false sense of security that it wouldn't happen, while leaving the man-in-the-middle attack ignored and vulnerable.

      There are basically two kinds of attacks: Man-in-the-middle (MITM) and blind attack which cannot see responses. UDP Port randomization makes blind attacks quite nearly impossible, and this has been known since 1999 or before. TCP DNS makes blind attacks impossible.

      If the attacker is in the middle, it d

  • by Anonymous Coward

    I've got verizon and when I look up non-existent TLDs I get back a records of,, and

    Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.

    So, WTF, and will DNSSEC make any difference in this?

  • I was actually thinking about this the other day.
    Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
    The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
    If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.
    • Re: (Score:3, Interesting)

      by Todd Knarr ( 15451 )

      There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).

      If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certi

      • That isn't what the original poster meant by security. Encryption only secures the transport, that does not mean SSL and TLS secures HTTPS from any exploits.

        • Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoi

      • by Lennie ( 16154 )

        This is actually one of the things I'd love to see if DNSSEC actually does get going for real.

        I'll love to be able to put SSH pub-keys and SSL(https) pub-keys in a verifiable DNS.

        At this point tooling, etc. really needs to be improved if I'm going to implement DNSSEC on my domains.

        The whole key-rollover stuff is still to complicated.

      • by rho ( 6063 )

        If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.

        Your suggestion just gave me the piss-shudders.

        A lot of people are

        • Why should it be hard? We're not talking about getting a CA-signed certificate verifying identity here, it's a self-signed certificate to insure that only the person who created the account accesses it. Prompt for a couple of things like name, generate and sign and add to the appropriate certificate stores for use. Assuming you're not just reusing a certificate you've already generated. This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more tha

          • by rho ( 6063 )

            Why should it be hard?

            And then:

            This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more than the bare basics of SSL.

            I think you answered yourself.

            The Web works because it has very low friction. Having to play idiot games with certificates and managing them adds tremendous friction. That you don't seem to see this suggests you haven't thought very carefully about the consequences of such a system, if at all.

            The reason why DNSSEC seems to be su

            • That's the thing, though: it shouldn't need to add significant friction. There's no games to play, and minimal management that ought to be needed. It should be about as complicated as keeping track of the credit cards in your wallet, which seems to be well within the realm of the majority.

            • Some parts of the DNSSEC process invite clean UI connections - setting the keys, running human-oriented query tool, etc. It's far easier if you include registering the key as part of the process of registering the name, of course. But that's not how most people use DNS.

              So you type a URL into your browser, and the browser hands it to a a resolver client, and the resolver client does a query. With Vanilla DNS, if the query fails, the client tells the browser it fails, and the browser either gives you so

    • by Anonymous Coward

      That's kind of the point. Dan has found a flaw in the basement of your house.
      The entire house is in jeopardy, no matter how well built. Every house affected.

      Do you :
      A: Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.
      B: Stucco and paint every 10 days, whistling to yourself forcefully.
      C: Try to jackhammer out the flaw and form up some new foundation meantime
      D: Nuke the house from orbit, start from scratch, total web tech re-over in IPv6

      I think Dan proposes C and eventually D. Mos

  • Dumb Question (Score:3, Insightful)

    by John Hasler ( 414242 ) on Thursday June 25, 2009 @01:32PM (#28468761) Homepage

    But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?

    • Nothing's perfect, but the DNSSEC signature process is mostly out in the open - you can see the public keys for the name servers, and you can check the signatures on the keys for yourself, and you can also get yourself domain names almost anywhere in the world if you don't like a given registrar/registry. So while a government _could_ probably bully a registry into signing a forged certificate for your domain name, it would at least be publicly visible that "your" key had changed.

      Also, the government foot-

      • > So while a government _could_ probably bully a registry into signing a forged
        > certificate for your domain name, it would at least be publicly visible that "your" key
        > had changed.

        That's not what I meant. I was wondering how easily they could manipulate it to gain additional control over the Net.

  • I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam. As others pointed out, this is a group of shysters. MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.

    Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC: []

    One of the things not detailed in my NTIA comments is that Kaminsky tells people t

    • > ...I could not get .ORG TLD officials to respond to questions about whether there was
      > regulatory approval for their actions.

      Are you saying that they may actually have done something *without permission*? Awful. Just awful.

      • The .ORG operator won't respond to the question of whether they had regulatory approval to carry out this action.

        A Top Level Domain(TLD) is operated under the supervision of ICANN and IANA, just like the root DNS servers. So TLDs should should have permsission from ICANN & IANA (and so from the NTIA of the Department of Commerce of the US Govt)--again--just like the root DNS servers need approval. The NTIA requested comments on DNSSEC(which I responded to) but NTIA has not announced any authorization to

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972