Forgot your password?
Security The Internet Technology

5 Years After Major DNS Flaw Found, Few US Companies Have Deployed Long-term Fix 313

Posted by Soulskill
from the rome-wasn't-built-in-5-years-either dept.
alphadogg writes "Five years after the disclosure of a serious vulnerability in the Domain Name System dubbed the Kaminsky bug, only a handful of U.S. ISPs, financial institutions or e-commerce companies have deployed DNS Security Extensions (DNSSEC) to alleviate this threat. In 2008, security researcher Dan Kaminsky described a major DNS flaw that made it possible for hackers to launch cache poisoning attacks, where traffic is redirected from a legitimate website to a fake one without the website operator or end user knowing. While DNS software patches are available to help plug the Kaminsky hole, experts agree that the best long-term fix is DNSSEC, which uses digital signatures and public-key encryption to allow websites to verify their domain names and corresponding IP addresses and prevent man-in-the-middle attacks. Despite the promise of DNSSEC, the number of U.S. corporations that have deployed this added layer of security to their DNS server is minuscule."
This discussion has been archived. No new comments can be posted.

5 Years After Major DNS Flaw Found, Few US Companies Have Deployed Long-term Fix

Comments Filter:
  • by Anonymous Coward on Tuesday January 29, 2013 @03:16PM (#42729865)

    DNSSEC is a flaw too! Once I watched a keynote from Daniel J. Bernstein at FISL pointing out all the flaws that make DNSSEC vulnerable. So he pointed to a better solution called DNSCurve:

    • Furthermore see Moxie Marlinspike's criticisms of DNSSEC: []

      About 2/3 way down the page.

      • by Anonymous Coward

        He doesn't get it. People who tout SSL keys in DNSSEC are very aware of the hierarchical nature of the DNSSEC trust relations and who we would be trusting if we used DNSSEC to distribute SSL keys. The point is that we're already trusting the very same people now, in addition to the CAs, and they're not even using trustworthy DNS yet. When you get a certificate from a no-frills CA, you only need to be able to receive mail at one of a few local parts under the domain that you want the certificate for. Bam, ev

      • That isn't a criticism of DNSSEC. That is a criticism of using DNSSEC for things other than DNS resolution. Domain names and IP addresses have to be allocated in a centrally managed fashion, so to avoid conflicts. DNS already has a hierarchical design by nature and DNSSEC simply makes it more secure.

        SSL key distribution/validation on the other hand doesn't have to be centrally managed, so adopting a hierarchical control structure like DNSSEC for that task is a suboptimal solution. In fact the problems in th

        • by dkf (304284)

          In fact the problems in the CA system we currently have directly stem from such a hierarchical trust scheme. We would be much better of going with a truly distributed system for SSL key validation.

          I'm unconvinced. (I'm particularly unconvinced by the handwave-assert-jedi-mind-trick style of argument there, but that's by-the-by.) The fundamental problem is that it is very hard to work out if the assertions in a public certificate are true; all you can tell is that the information was digitally signed by someone or something. With a web of trust model, either you have non-transitive trust (which totally doesn't scale at all!) or you have transitive trust, in which case all it takes is for one person to

    • by Bengie (1121981)
      From the sound of the wiki article, DNSCurve only secures the channel communicating to the DNS server, while DNSSEC secures channel and the actual DNS records.

      We need both secure communications and validation that the returned entries haven't been modified by the server itself.
      • by Anonymous Coward

        Having delved into both deeply, implementing DNSCurve in one server and partially having implemented DNSSEC elsewhere, I can give you a better comparison.

        DNSCurve secures the channel between a recursive DNS cache and upstream authoritative servers. It does not attempt to secure the client->cache channel, although there have been related proposals (modifications of the same basic guts DNSCurve had) to secure that channel as well. DNSCurve is designed for a world where you implicitly trust your cache. E

        • by marka63 (1237718)

          DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.

          DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetecte

  • Sweden Innovates (Score:5, Informative)

    by ptudor (22537) on Tuesday January 29, 2013 @03:17PM (#42729885) Homepage Journal
    So, there's OpenDNSSEC [] to automate deployments; I strongly suggest spending the time to watch the .SE NIC's nine-part training videos from 2010 at Youtube to improve one's understanding: []

    Some respected members of our community dismiss DNSSEC. This video of DJB presents an opinion: DJB at 27C3 []

    • Why choose this instead of powerdnssec? I strongly suggest the dnssec training at [] (flash) to improve one's understanding of the dnssec protocol. And powerdns to implement it []

      BTW dnssec adoption is amongst the highest for .nl in absolute numbers of domains, simply because there is a bounty for every domain signed. If you have a few hundred of domains the costs to implement are lower than the discount given till mid 2014

      • by ptudor (22537)
        Why choose one over the other? I don't care :) So far people have chosen neither.
        • by kwark (512736)

          Nobody is using them? 1/5 of the .nl domains are registered DNSSEC domains:

      • by mooingyak (720677)

        If you have a few hundred of domains the costs to implement are lower than the discount given till mid 2014 == profit for implementing dnssec

        I'm assuming there's some kind of catch in there so that it's not worthwhile for someone to register a few thousand new domains and then implement DNSSEC on them.

        • by kwark (512736)

          No catch, just a discount per domain registered for dnssec (0.28 EUR/year). I have about 1k .nl domains, I spend a few days figuring out what dnssec was about, how to implement, test and maintain it. Activated it on the corporate domain, some personal and a couple of test domains and waited 2 months to see if there were problems (none). So now it is active for all domains saving us 420 EUR till the discount ends in 2014-06. For us it was not enough to cover the expense of my time, but this had to be implem

    • videos? Does noone know how to rite anymore?

      Aargh - the next fucker is telling me to look at some flash shit!

      • by kwark (512736)

        If you just kept reading instead of getting distracted by flash, you'd have seen the next link point to human readable text explaining (briefly) how dnssec works and how to implement it for a specific named. I just have to hope you read past flash this time.

    • by drinkypoo (153816)

      If I need to watch a nine-part training video to understand DNS, then someone has fucked up DNS. That is bullshit.

  • by dkleinsc (563838) on Tuesday January 29, 2013 @03:32PM (#42730057) Homepage

    Many potentially targeted organizations will not spend the time and money to make the necessary changes without prodding. I've seen this in payment security too: A lot of companies are shocked and dismayed when they find out that they are supposed to store credit card numbers in some way other than in plaintext in a database accessible to anyone with the single database login that everyone in the company has.

    The only thing that will prod them is experiencing a cost of doing nothing that is higher than the cost of implementing the solution.

  • by whois (27479) on Tuesday January 29, 2013 @03:33PM (#42730077) Homepage

    It broke access to several DNSSEC enabled websites that were misconfigured. After a few months of support problems where we suggested the websites fix their issues and they ignored it, it was requested by management that we turn it off.

    It's a very bad design as it stands now. It's unable to return any error but NX Domain for DNSSEC errors for reasons of backword compatibility, which is stupid since you need a DNSSEC enabled resolver to make the request.

    It also has an incredibly steep learning curve that even experienced public key administrators face problems with.

    • by bbelt16ag (744938)
      sounds like job security..
    • by anom (809433)

      This. I recently set up a new name server and had to disable it for similar reasons.

      • by nullchar (446050)

        Would either the parent or GP like to list some sites that were broken with DNSSEC? There are some decent tools to test DNSSEC queries, so I'm surprised the DNS admins for the broken zones have left it broken. There's not really any half-assed zone signing with DNSSEC, you either sign the entire zone or you don't.

    • by gweihir (88907)

      And there is the little problem that in the long run, its certificate system is just as broken as the SSL cert system is now. My guess is it is not worth the effort at all.

      • by kwark (512736)

        "its certificate system is just as broken as the SSL cert system is now"

        Can you explain this? DNSSEC hasn't got much common with the SSL cert system. There is only 1 root authority, the weak point during a key change. Each domain/tld has their own (multiple) keys. tld and domains should regenerate the short Zone Signing Keys fairly often (a couple of weeks), while the bigger Key Signing Keys should be regenerated about once in a year. If a tld is compromised it only has to create a new KSK, individual domai

        • by gweihir (88907)

          Too many people in there. Somebody will either mess up or be corrupt. A PKI only works in practice if there is a single CA or a very small number of CAs under tight control. Ignoring the non-technological angle is just incompetent.

          • by kwark (512736)

            But there are no CAs in DNSSEC. There are only public/private keypairs under control of the owner of the domain.
   has 3 pairs/signatures to check:

            • .
            • com.

   tells the com. authority what it's public KSK is.
            com. tells the root zone what it's public KSK is.
            The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).

            • by dkf (304284)

              The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).

              The usual way with PKI is to have two identities involved in the root. One, the master, has a public key very widely known and with a very long life, and only ever used to validate the "operational key"; the master private key is kept offline in a safe somewhere. Perhaps with armed guards or something like that. The operational key is what is used to validate child domains, and as such is in use a lot more and so is more exposed. On the other hand, you can generate new ones (with only the hassle of the arme

            • by gweihir (88907)

              And that makes com a CA. Or how do you think the signature of com gets onto the public key of Magic?

              • by kwark (512736)

                "Or how do you think the signature of com gets onto the public key of Magic?"

                It doesn't. And you are confusing a web of trust with CA, it's like PGP. com. can only tell a dnssec user what it thinks the public KSK of is. That should have been communicated in a secure way to com. It is oneway trust between direct parent-child relations in the dns tree.

          • by idontgno (624372)

            Well, if your assertion is that "people are a problem", you're not the first to make that observation. [].

            It's a little-considered fact that 100% of insider crime is committed by insiders.

            Short of extincting the human race, I don't see a good solution. Maybe we should not fixate on the insolubles?

            • by gweihir (88907)

              Indeed. The problem I see with things like DNSSEC is that it implies trustworthiness that may well not be there, hence I understand why people are not bothering with it. (Aside from it being another protocol monster form a really clueless tram...) It is also generally not needed for things like remote access, just use 2-sided authentication.

    • by Anonymous Coward

      Except the largest cable ISP in the US, Comcast, has DNSSEC resolvers enabled for customers by default, and they manage to deal with these problems.

      They even track and publish informaiton of (large) failing domains and in the backend work with website owners to notify them of the deficiancies. As a Comcast customer, I notify the Comcast DNS folks whenever I have DNSSEC problems, as they have a large amount of clout and will use it to notify website owners.

      More large ISPs need to get on board - when we have

      • by whois (27479)

        We beat Comcast to the punch by about a year. I'm happy that they turned it on and can afford to support it, but 90% of the customers you have are dumb and don't care why it doesn't work from your ISP, they just care that it works at Starbucks and doesn't work at their house.

        Being a huge monopoly has an advantage when it comes to telling customers to pack it up when they have DNS issues. I too am a comcast customer and I run my own resolver (for flexibility, not because they implemented DNSSEC)

        All the dom

    • by KiloByte (825081)

      It also has an incredibly steep learning curve that even experienced public key administrators face problems with.

      There's a way to do it in the name server itself, but here's a way for newbies:

      1. in named.conf.local, change file ""; to file "";
      2. where you would do rndc reload after a change, you instead do zonesigner --usensec3 -zone && rndc reload
      3. read the key-signing key zonesigner created, log in to your registrar, add a DS record by pasting data from that file
      4. if you want the keys to expire (zonesigner's default), s

  • SIDN (the maintainer of .nl) offers a small discount to domains that use DNSSEC. This was sufficient motivation for a few large hosting companies to enable DNSSEC across all their domains. In just a few days a fifth of all Dutch domains switched over. By now 26% of the .nl domains (1.381.790 out of 5.153.408) use DNSSEC.

  • Because the standards are a pain in the ass and most implementations are needlessly complex.

    • by bbelt16ag (744938)
      then fix it! whats your excuse now? and if you can't then complain to the ones who can.
  • by gweihir (88907) on Tuesday January 29, 2013 @04:11PM (#42730595)

    If your security depends on DNS working, you are screwed anyways. That is likely the main reason nobody uses DNSSEC: It does solve the wrong problem.

    1. The sane way for remote access it is to require 2-sided authentication on connection, making DNSSEC entirely redundant.
    2. For the open web, things are a bit differently, but there you can land on a malicious page any time and the only solution for that is a not vulnerable browser or a secure browsing environment.

    There is also the small issue that DNSSEC is badly borked and a nightmare to install and maintain. In addition, the other PKI (SSL certs) is badly broken, and there is really no reason the DNSSEC PKI would fare any better if widely deployed. In the long run, it is very likely that DNSSEC is just a waste of time and effort.

    • by jd (1658)

      2-sided authentication was mandated in the early IPv6 specs by the IPSec mechanism. Sun offered an alternative, SKIP.

      Since then, both have been ported to IPv4.

      IPSec is occasionally used by VPN clients, but that's about it. Most VPN clients are run on laptops or other portable devices, often over a wireless link. This is where Sun SKIP was stronger than IPSec, which is ideal for a wired network but gets noisy when you've links that aren't guaranteed stable and error-free.

      Regardless, neither is used for meani

      • by gweihir (88907)

        And this is relevant how? IPsec is known to be another protocol monster by clueless designers. How IPsec ever passes the IETF process is a mystery to me. Numerous people must have messes up simultaneously.

        TLS (as in OpenVPN, for example) and SSH for UNIX provides a much better basis for 2-sided authentication, and both are in widespread use.

        • by jd (1658)

          TLS vulnerability on Slashdot frontpage today.

          SSH is of dubious value as it encrypts only select channels, whereas the remaining channels may contain sufficient information to pose a significant vulnerability.

          Give me something that WORKS, for Pete's sake, and not this backyard crap.

      • by dmelomed (148666)

        The problem with IPv6 adoption is its design, not politics. It was designed as a replacement instead of IPv4 backward-compatible extension. An administrator and end-users have to go through hoops to make this garbage work, and that's why nobody wants to. Why should/would they? IPv6 should have been designed such that neither administrators, nor end-users would have to do much to upgrade.

        • by jd (1658)

          IPv4 is intrinsically incapable of being secured. So, if you want to design a secure IP protocol, you cannot have one that is backwards-compatible.

          IPv4 is also necessarily fragmented - there is no correlation between IP address and location within the network, leading to bloat in router tables, inefficient routing decisions, excessive latency and greater vulnerability to MitM attacks via router poisoning.

          IPv4 requires manual configuration, whereas IPv6 is autoconfigurable by design.

          IPv4 has support for IP M

  • How "major" is the flaw when there are few reports of it being used in attacks? People will change their behavior when there is a real reason to do so. Until there is an upswing in DNS cache poisoning, most will see no reason to go to the expense of converting. As another poster pointed out, there are plenty of other techniques attackers are using to impersonate websites.
    • by jd (1658)

      There are few reports of people flying planes into office blocks. People changed behavior, not because there was a reason, but because it was highly visible.

      There are many reports of drunk driving fatalities every day. (More die in road accidents per day than have died in terrorist attacks in the past decade.) Nobody changes their behavior because these deaths are NOT highly visible.

      People don't give a shit about risk assessment (and aren't capable of it anyway), people only care about the emotional, visibl

      • When I say 'reports' I refer to the data on successful attacks, not necessarily 'news'. Despite your assertion, there are several sources of such data. And you'll have to provide a citation regarding how much fraud is taking place with no indication of how. According to some of the other posters here. moving to DNSSEC is not 'very low cost maintenance', so doing it when the apparent threat is very close to zero is in most cases going to be judged a waste of time.
        Regardless, my intended point could be phra
        • by jd (1658)

          Most of the vulnerabilities we live with are stupid and are only there because humans are incapable of assessing risk. (Those times I refer to myself as an elf, it is because I completely disavow any association with such monstrous stupidity and there are no existent homo sapien subspecies recognized that I could otherwise label myself as. As it is, I am debating whether to lobby the scientific establishment on nomenclature because there's bugger all evidence of any wisdom amongst the humans I've encountere

          • humans are incapable of assessing risk

            Well that's not true. Humans assess risk all the time. For example, I drove today even though I know there is a chance I could get in a fatal accident. Just because the assessment of others doesn't agree with your assessment doesn't mean they are stupid or wrong.

            • by jd (1658)

              First, look up the research and don't base your arguments on Anecdotal Evidence (even your own). The peer-reviewed research says they are stupid and wrong, therefore they are stupid and wrong until there is sufficient evidence to reject that hypothesis. Given your use of Anecdotal Evidence, it is clear that such a rejection may take a while.

              Second, I am old enough to be tired of the utter ignorance of the world around me. I've been deep into science for longer than most Slashdotters have been alive. Hell, I

  • And the Dans are both tools (Kaminsky and Bernstein). And to the guy who suggested hosts files with nasty scripts copying things to and fro, ummm... NO. Sounds like some of the horror stories I've heard of how things are cobbled together at a certain large Seattle-based internet retailer, and it's the kind of hair-brained idea a DevOps fan might dream up.

  • Really quickly:

    • DNScurve, as pointed out above, doesn't do nearly as much as DNSSEC does. In particular, DNScurve still allows "NXDOMAIN recirection" but DNSSEC doesn't. In addition, Bind, NSD, Unbound, and PowerDNS (non-recursive) have DNSSEC support, but there is not a mainstream DNS server out there with DNScurve support.
    • djbdns hasn't been updated since 2001 and even the unofficial forks do not have patches for all three CVE security holes in DjbDNS []. Since DjbDNS' goal was security, I consider it a
  • by Anonymous Coward

    DNSSEC has nothing to do with the Kaminsky attack.

    The Kaminsky attack took advantage of what was essentially bad randomness in DNS resolver implementations.

    DNSSEC solves the problem of DNS being plaintext (and consequently vulnerable to man-in-the-middle attacks) in the first place. If you want to call that a "vulnerability", it's one that's been around (and known) for as long as DNS; I guess ~30 years? Current internet culture requires more security so DNSSEC throws a layer of cryptography on top of tradit

  • My DNS provider was planning to deploy DNSSEC signing several years ago, but they still haven't.

    They claim the reason is that since DNSSEC responses are 75x the size of vanilla DNS responses, this makes DNSSEC providers more vulnerable to DDOS attacks.

Live within your income, even if you have to borrow to do so. -- Josh Billings