I've read several papers on DNSSEC, and it appears that it does prevent many attack classes, and the only two possible downsides is that its deployment is hard (DNSSEC is complex), and that you can walk DNSSEC records and find out all records in your domain. Also, not all TLDs support DNSSEC.

I tried all .com domains in Alexa's top sites list (first two pages), and only paypal.com on the second page has DNSSEC records. That's out of more than 30 top .com domains...

Surely sites like Gmail, Ebay, Amazon can benefit from extra security offered by DNSSEC. Since not one of them actually deployed DNSSEC, I must conclude they know something bad about DNSSEC that overweights the benefits offered by it. What that could be?


It is actually unclear whether DNSSEC is "what we want".

Right now, the certification of Web site, i.e. how a Web browser makes sure that it talks to the right site (when doing HTTPS) is done with digital certificates emitted from about a hundred of Root Certification Authorities. The root CA are entities who decided to go into the certificate issuance business, and what makes the hundred-or-so special is that they made a deal with Microsoft/Apple/Mozilla/Google so as to include their public key in the "trusted" store of every browser (or operating system). The deal includes a lot of legalistic gizmos and insurances.

Though often criticized for its opacity, public cost of individual certificates, and a few well-publicized blunders (lookup "Comodo" and "DigiNotar"), the PKI system tends to work, in an economic sense: commercial sites use them, and the CA are very rarely attacked (most attacks are about inducing the gullible user into ignoring the scary warnings that the browser emits when it finds something fishy with the certificates, rather than going to the trouble of subverting an existing CA). There is then relatively little incentive to change things (that is, there are a lot of people who would prefer another system for a variety of reasons, but, ultimately, these things are decided by those who pay for it).

DNSSEC is about taking these root CA out of the loop, and instead give the certification power to the people who maintain the DNS (the mapping from server names to IP addresses), in such a way that the two structures would be bound together: domain name inheritance (with the notion of "sub-domain") would be merged with PKI inheritance (with the notion of "intermediate CA").

It is unclear whether the new tenants would be more competent at the CA business than the previous; as I said, the actual system works already quite well, and certification is not the same craft as mapping names to addresses. It is also unclear whether such concentration of powers is really a good thing. For the big players, it would not change anything: Verisign-the-CA and Verisign-the-registrar are both Verisign.

On the technical side of things, DNSSEC offers easy distribution of certificates (aka "signed bindings of identities to public keys") through the DNS system, but that's not a problem which needed to be solved: right now, any SSL/TLS server happily sends his certificate chain as part of the initial handshake, and it works well.

Thus, given the uncertainties about the goodness of DNSSEC, and the lack of flagrant issues with the existing PKI, it is no wonder that deployment is deemed non-urgent by the big companies. Let's get IPv6 working first.

As indicated by the comments below, DNSSEC has some value as itself for authenticating DNS information, which blocks DNS poisoning. DNS poisoning is the easy way to do a Man-in-the-Middle attack, but it would be wrong to believe that this solves MiTM issues; it just makes things a bit harder for the attacker (e.g. the attacker must use a WiFI-pineapple instead of simply abusing a hole in an existing WiFi hotspot). Getting guarantees about the mapping of a name to a given IP address does not get you far if you cannot know whether a given packet really comes from the IP address which is written in its header.

Either way, it does not provide much added value to the big servers, and that's sufficient to explain their reluctance.

(DNSSEC has military value, though: by preventing DNS poisoning, it helps in defending against big denial-of-service attacks that could be part of some global electronic warfare. I expect DNSSEC to be supported by governments, not by big companies -- but the days or ARPANET are long gone, and the Internet is the territory of private ventures nowadays.)

  • 10
    I think you're mixing together different technologies here, e.g. anchoring the PKI trust chains into DNS instead of CAs requires DNSSEC, obviously, but it is not the stated reason DNSSEC was created, e.g. preventing DNS spoofing is beneficial as-is, even with today's PKI. And I disagree with "lack of flagrant issues with the exisitng PKI", but it's off-topic here. – haimg Oct 4 '12 at 17:32
  • 14
    DNSSEC is about taking these root CA out of the loop -1 on that. It can be used that way, but DNSSEC is authenticating the domain request chain. The current SSL scheme can continue without modification while DNSSEC is still supported on queries. Maybe this whole Moxie Marlinspike / Dan Kaminsky debate has clouded the core of DNSSEC: authenticating the DNS queries and chain from root independent of any services. – Jeff Ferland Oct 4 '12 at 17:33
  • 3
    What @Jeffferland said. Also, adoption of DNSSEC has to be top-down which means that if a given TLD hasn't yet signed its master zone there's no point for anyone underneath it to start setting it up... – Shadur Nov 20 '13 at 12:10
  • 3
    Also verisigninc.com/en_US/innovation/dnssec/what-is-dnssec/…, [DNSSEC's] job is done once the user reaches the address. DNSSEC does not ensure the identity of the entity at the address, and it does not encrypt interactions between the user and the site. SSL uses digital certificates to validate the identity of a site. When these certificates are issued by reputable, third-party certificate authorities (CAs), SSL assures users of the identity of the website owner. However, SSL does nothing to ensure that a user reaches the right site, so it is not applicable... – Pacerier Feb 16 '15 at 15:15
  • 1
    @David天宇Wong Why? DNSSEC is just as important for https:// connections. It verifies that the DNS record you've received is the one published by the owner of the domain - i.e. that the IP you're connecting to when you go to example.com is in fact the host the example.com admins want you connecting to (and not some result of cache poisoning that's presenting you a bogus DigiNotar certificate pretending to be example.com to steal your information). – voretaq7 Jan 10 '17 at 21:02

The only thing wrong with DNSSEC is that it's new, DNS is (obviously) important and people are reluctant to mess with their DNS setup. If your DNSSEC deployment goes wrong you could loose your entire internet presence.

As to why you'd want to authenticate DNS lookups, read this paper on how the great firewall leaks onto users outside of China:


It's not just China that mucks about with DNS, anyone with access to the traffic between a client, the client's resolver or the resolver and your dns servers can alter responses as well.

Certificates for websites are only a small part of the puzzle here.

  • You are being overly optimistic: there are a lot more things wrong about DNSSEC than it simply being new. blog.opendns.com/2010/02/23/opendns-dnscurve cr.yp.to/talks.html#2009.08.11 cr.yp.to/talks/2009.08.11/slides.pdf – cnst Nov 20 '13 at 6:46
  • 1
    @JasperWallace, Google is implementing things that are much much newer than DNSSEC. I don't think "new" is the reason they ignored DNSSEC. The huge cost of signing every single DNS query seems to be a better reason, due to current hardware still not being fast/cheap enough. That kind of cost is only justified if you are doing something like Paypal. – Pacerier Feb 16 '15 at 15:17
  • 1
    @JasperWallace, And DNSSEC isn't new at all. It's been decades. The major thing wrong with DNSSEC is that it places the trust in the governments (dns resolvers). This means that if you visit a bit.ly link, the person in charge of .ly (Libya government) could hijack your connection. Yes, someone like Muammar Gaddafi. See sockpuppet.org/blog/2015/01/15/against-dnssec – Pacerier May 22 '15 at 4:49
  • 5
    Gadafi's dead btw, and with or without dnssec, if you don't trust libia .ly is unusable. – JasperWallace May 23 '15 at 19:59
  • HPKP preload (which has its own problems) wouldn't require trusting Libya for securing bit.ly, for example. – Tgr Nov 18 '17 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.