31

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?

mlp
  • 546
  • 4
  • 8
haimg
  • 475
  • 4
  • 7

3 Answers3

18

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

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 12
    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 04 '12 at 17:32
  • 17
    *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 04 '12 at 17:33
  • 4
    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
  • 4
    Also http://www.verisigninc.com/en_US/innovation/dnssec/what-is-dnssec/index.xhtml, *[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
  • It could be clever to only enable DNSSEC when not trying to reach a https:// address – David 天宇 Wong Jun 08 '15 at 19:22
  • 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 https://www.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
  • if the DNS records receive are incorrect, the "wrong" website will still have to present a correct certificate (because https). CAs protect you from that. – David 天宇 Wong Jan 16 '17 at 21:55
  • but if just *one* certificate provider is compromised then a forged certificate could be created, which would then be trusted by the browser, once the DNS is redirected, and DNS would be trivial to redirect over public wi-fi or through other local access. so DNSSEC would defend against forged certificates. of course, the above scenario wouldn't work if the client has previously connected to a domain which has an active HPKP rule. the other major advantage is DNSSEC is decentralized, and i think the internet has become too controlled by corporate powers. – infinite-etcetera Sep 19 '17 at 10:53
13

8 Years Later:

I must conclude they know something bad about DNSSEC that overweights the benefits offered by it.

Not necessarily. Just as any other technology, the question is what incentives are there for involved stakeholders?. If you take a look at ICANN's DNSSEC report you can see that nearly all TLDs currently support DNSSEC.

So why consumers do not use it? Well it is also not easy to answer. In general if you don't want to go through the hassle of running your own name servers, you are dependent on the registrar to take care of some features such as DNSSEC. A Study by Chung et al. in 2017 [1] showed that "only three of the top 20 registrars support DNSSEC when they are the DNS operator". Even if your name server is properly configured to use DNSSEC, there is no guarantee that users use (recursive) resolvers that are DNSSEC-aware and properly verify DNSSEC records [2].

Poor security usability for the end-users is probably another negative incentive for potential adopters. Compared with TLS, where you'd get warnings and errors directly in your browser in case of invalid certificates, there is no visual cue for DNSSEC (you can check if a website is signed or if your resolver validates DNSSEC on https://internet.nl/).

To give another twist to the whole story, lack of DNSSEC is sometimes desired by some parties. DNS poisoning for example opens the door for domain impersonation which can also grant you a domain validation (DV) certificate [3] which practically enables you to spoof a legitimate entity even with a valid certificate (green padlock in the address bar). Another example is the tr TLD which does not support DNSSEC; now combine this with how the government of Turkey once abused DNS for censorship you can draw your own conclusions.

[...] and that you can walk DNSSEC records and find out all records in your domain.

This is not the case anymore with NSEC3.

Update:

I forgot to mention RFC 3833, which not only enumerates DNS security threats, but also weaknesses of DNSSEC:

  • DNSSEC is complex to implement.
  • DNSSEC significantly increases the size of DNS response packets.
  • DNSSEC answer validation increases the resolver's work load.
  • Like DNS itself, DNSSEC's trust model is almost totally hierarchical.
  • Key rollover at the root is really hard.
  • DNSSEC creates a requirement of loose time synchronization.
  • The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably.

[1] Chung, T., Levin, D., Van Rijswijk-Deij, R., Maggs, B. M., Wilson, C., Choffnes, D., & Mislove, A. (2017). Understanding the role of registrars in DNSSEC deployment. Proceedings of the ACM SIGCOMM Internet Measurement Conference, IMC, Part F1319(July), 369–383. https://doi.org/10.1145/3131365.3131373

[2] Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, B. M., Mislove, A., & Wilson, C. (2017). A longitudinal, end-to-end view of the DNSSEC ecosystem. Proceedings of the 26th USENIX Security Symposium, 1307–1322.

[3] Schwittmann, L., Wander, M., & Weis, T. (2019). Domain impersonation is feasible: A study of CA domain validation vulnerabilities. Proceedings - 4th IEEE European Symposium on Security and Privacy, EURO S and P 2019, 544–559. https://doi.org/10.1109/EuroSP.2019.00046

Community
  • 1
Yan Foto
  • 251
  • 2
  • 6
  • 1
    The registrars haven't implemented DNSSEC for their customer DNS probably beause it requires signing the whole zone again every time a single modification is made. RFC 5702 only had RSA/SHA based algorighms for zone signing, which made it quite a heavy process. RFC 6605 with ECDSA/SHA signing made this a lot faster. – Esa Jokinen May 13 '20 at 12:41
  • 1
    BTW welcome to Security SE and thanks for the good answer with proper references! – Esa Jokinen May 13 '20 at 12:42
  • @EsaJokinen thanks! This is by far the best welcome I have ever received on any StackExchange sites :-) – Yan Foto May 13 '20 at 14:05
  • 1
    @EsaJokinen You don't have to resign the entire zone when a record set is modified. You have to sign the record set, SOA record (if you updated the serial number), and affected NSEC(3) records. And you may not have to sign anything immediately if you do online signing. – Matt Nordhoff May 23 '20 at 17:21
  • Are you referring to "Inline Signing"? Typically BIND takes a complete unsigned zone and signs every record, also updating the SOA serial in order to trigger zone transfers. Probably it's technically possible, but might require some own NS implementation? – Esa Jokinen May 23 '20 at 17:36
  • @EsaJokinen CloudFlare for example does fully online signing (aka generating signatures when needed, not in advance like offline signing): https://blog.cloudflare.com/dnssec-done-right/ – Patrick Mevzek Jul 20 '22 at 22:57
8

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:

http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf

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.

JasperWallace
  • 446
  • 3
  • 5
  • You are being overly optimistic: there are a lot more things wrong about DNSSEC than it simply being new. http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://cr.yp.to/talks.html#2009.08.11 http://cr.yp.to/talks/2009.08.11/slides.pdf – cnst Nov 20 '13 at 06: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
  • 2
    @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](https://en.wikipedia.org/wiki/Muammar_Gaddafi). See http://sockpuppet.org/blog/2015/01/15/against-dnssec/ – Pacerier May 22 '15 at 04:49
  • 6
    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