14

I have read through the questions tagged DNSSEC on this site, and over the years you hear statistics about DNSSEC adoption and about organizations enabling it on their domains... but nobody mentions what they are actually trying to solve. Well, that it "signs DNS responses", but that's a method and not a goal.

"IP spoofing will no longer be possible," tech news will write when the topic comes up. Or "DNSSEC allows domain name owners to sign their DNS records" howtogeek writes. Yet if I, as an attacker, could spoof a DNS response, I am probably a in the middle with apparent read/write-access to the connection, allowing me to modify the contents regardless. Or if someone uses HTTPS, it does not matter whether I can spoof the IP address because I don't have a matching CA-signed certificate.

It doesn't even make sense that domain owners can sign their DNS records, because how would the public keys (used to sign the data) ever end up with the DNS clients? Beyond it seeming hugely inefficient to bloat each DNS response, if you combine the public key with the signed data, it's an easy operation to swap out the public key along with the signature.

An attack that is supposedly thwarted by DNSSEC is DNS cache poisoning, but wasn't that a solved problem by having recursive resolvers use randomized source ports?

Additionally, I heard from my ISP (Dutch) today that they are enabling it. Wasn't it the domain owners that signed the records? Moreover, I also read of the SIDN (owner of the Dutch TLD .nl) that they enabled it a while ago. They even have a counter on their homepage counting the number of DNSSEC-enabled domains. Some registrars (e.g. TransIP) enabled it as well. Who is signing these things: the domain owners, registrars or TLDs?

Lastly, not everything is signed. It seems that some domains have DNSSEC enabled and some don't (even if they're both from the same top level domain). How will a client ever know whether it was supposed to be signed? It seems like an easy attack to just strip out the signature when spoofing a response.

Could someone explain:

  • what is the goal of DNSSEC?
  • who has to have it enabled in order for it to work?
  • who signs a domain?
  • how can clients detect a signature being removed?
Community
  • 1
Luc
  • 31,973
  • 8
  • 71
  • 135
  • This might help? [RFC3833: Threat Analysis of the Domain Name System (DNS)](https://tools.ietf.org/html/rfc3833) –  Nov 14 '16 at 20:16
  • 3
    In my opinion your question is too broad since your are effectively asking about the problem DNSSec is trying to solve (purpose), they way it works (technology), what domain owner and user have to do to use it (administration, deployment) etc. Each of these by itself would be a large enough question already so please restrict yourself to a smaller question. – Steffen Ullrich Nov 14 '16 at 20:18
  • 1
    @SteffenUllrich I see where you are coming from; I just thought it a good idea to have a single reference point with general high-level answers about what it solves and how it solves it, similar to [How to securely hash passwords?](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) or [How does TLS work?](http://security.stackexchange.com/q/20803/10863) – Luc Nov 14 '16 at 20:57
  • 2
    http://security.stackexchange.com/questions/11566/how-does-dnssec-work-are-there-known-limitations-or-issues?rq=1 seems to answer you – schroeder Nov 14 '16 at 21:56
  • @schroeder Thanks! It answered some questions (not sure how I missed that question), but still not what problem dnssec is trying to solve. Since a rogue or hacked DNS server can still return signatureless responses, I cannot see it thwarting any kind of attack, unless dnssec is scheduled to become mandatory (disallowing unsigned responses altogether) upon 99% adoption or so. – Luc Nov 15 '16 at 07:58
  • It's up to the client to prefer (or alert) on non-signed responses, just like TLS on a web browser. – schroeder Nov 15 '16 at 08:00
  • @schroeder So in its current form, it is practically useless since, due to the relatively low adoption rate, hardly any software will ever alert on it? Is it like IPv6: not very useful until v6-only content arrives? – Luc Nov 15 '16 at 08:15
  • 1
    I'd say that it's like TLS: it informs the clients who are listening. – schroeder Nov 15 '16 at 08:17
  • @schroeder Yet with TLS clients explicitly choose to initiate the conversation over an encrypted channel (not counting starttls, that has a different purpose); with dnssec it's unknown whether a response should have contained a signature. Or am I missing something? – Luc Nov 15 '16 at 08:29
  • See also this: https://security.stackexchange.com/questions/91725/dnscrypt-vs-dnscurve – nmit026 Apr 07 '17 at 06:27

2 Answers2

6

1. What is the goal of DNSSEC?

DNSSEC signs DNS records. It does not encrypt, it just confirms authenticity.

The root signs keys from TLDs (such as .org or .de), TLDs sign keys from registrars, and registrars sign the DNS records that you (probably) put in via their web interface.[2]

You can also have them sign your keys so that you can maintain a signed zone yourself.[3]

DNSSEC exists of fields added to domains, so it's not something that works for every website after you turn it on for your computer. If a registrar does not support it, or if a TLD does not support it, your computer just cannot verify the authenticity of the records of the domain you're querying.

2. Who has to have it enabled in order for it to work?

We've already covered the root, the TLD of your choice and the registrar. Now ISPs or other recursive resolvers (e.g. OpenDNS) can also have it enabled or not. Having it enabled means their resolvers will check signatures and return an error code if the validation fails.[4]

The user's client also has to have something enabled in order for it to work: if your client (e.g. Firefox) does not alert on an invalid signature, the signatures will never add any value.[5]

3. Who signs a domain?

The registrar either signs your records or the key with which you sign your records. So you trust the registrar. If you don't trust the registrar, you will have to get a different one. And you trust the TLD, since they could just sign it with any key they like (since they can sign registrar's keys). And you trust the root for the same reason.

4. How can clients detect a signature being removed?

If someone removes the signature, presumably to modify records without triggering a signature validation error, it might appear that the domain simply does not have DNSSEC enabled. However, the parent signer (the TLD) will have mentioned that DNSSEC should have been enabled for the domain, and the TLD's response is signed so cannot be forged.[6]

So what if we remove the TLD's signature as well? Alright, then the root will tell us (with signature) that the TLD should have had it enabled.

If the root is trustworthy, and the root only signs legitimate TLDs, and the TLD is trustworthy, and the TLD only signs registrars, and the registrar is trustworthy, then you can be sure the signed records came directly from the domain owners.

5. Bonus: Does DNSSEC have any issues of its own?

It makes responses bigger (not a security but a performance issue) and helps domain enumeration.

Domain enumeration is made possible because of the way they solved NXDOMAIN signing. Signing is meant to be done offline so name servers don't have to sign things on the fly. But how do you sign a response, in advance, for something that doesn't exist? By signing a response that says "between ftp.example.com. and mail.example.com. there are no other records" and returning that when anyone asks for something like jkl.example.com.[1]

Now to enumerate, you start with aaaa.example.com. and it will tell you the first record, like ftp.example.com. Then you request ftq.example.com (one character incremented) and it will give you the next record.

This was solved by hashing the names and going "between hashes a8fba8[...] and da8a8bfdf[...] there are no other records". This is called NSEC3.[8] This still allows for hash enumeration and then offline cracking the hashes, which is orders of magnitudes faster and stealthier than guessing by querying the name servers.[9]

It's an ongoing discussion whether it's an issue that names can be enumerated. The people who design DNSSEC typically say that the DNS system was supposed to be a public phone book; the people who deploy DNS servers typically prefer to keep their phone book private.[7]

[1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3

[2] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Operation

[3] "you tell your registrar your signing key's fingerprint by creating a DS record" https://security.stackexchange.com/a/11571/10863

[4] "they enable their DNS resolvers (which you use to translate fancy domain names into IP addresses) to verify DNSSEC. So from now on, if you ask your ISP for the IP for a domain and the signature is invalid, you will get an error instead of the wrong IP." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] "It's up to the client to prefer (or alert) on non-signed responses, just like TLS on a web browser." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

[6] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Recursive_name_servers "If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on"

[7] https://security.stackexchange.com/a/11571/10863 "DNS (and DNSSec) was designed largely by folks in the first camp; [...] the servers tend to be run by people in the second camp"

[8] https://security.stackexchange.com/a/126518/10863

[9] https://dnscurve.org/nsec3walker.html See "Future work"

Community
  • 1
Luc
  • 31,973
  • 8
  • 71
  • 135
5

It solves integrity guarantee. It will no longer be possible to MITM a signed zone. Right now anyone could falsify DNS records, with DNSSEC they cannot. The client already knows the public key of the root zone and can verify the whole chain down to the zone.

When you register a domain, you must tell the TLD zone where your nameservers live. At that point, you can also attach a pubkey. The TLD zone signs your entry and from that point on, everyone can verify the integrity of your zone by checking with the TLD zone. Your own zone in turn can sign it's records. Since your pubkey is known and verified, only you can sign your zone. The TLD zone in turn is signed the same way from the root zone, and that public key is known by the DNS client. This way, if someone tries to spoof DNS responses, they would have to modify your DNS client first to either replace the stored root key, or disable DNSSEC completely.

John Keates
  • 820
  • 4
  • 7
  • Thanks for answering part of the questions. It still doesn't tell me what role my ISP plays in this (since they announced enabling it) or how stripping signatures from responses is detected (if at all). – Luc Nov 15 '16 at 07:29
  • 1
    I don't speak dutch but from what I understand they enable their DNS resolvers (which you use to translate fancy domain names into IP addresses) to verify DNSSEC. So from now on, if you ask your ISP for the IP for a domain and the signature is invalid, you will get an error instead of the wrong IP. – Josef Nov 15 '16 at 07:39
  • 1
    @Luc The ISP is the one supplying you with 2 (or more) default DNS servers. If their servers don't support DNSSEC, any records they make are not going to be signed at all, and if they have some upstream error (i.e. a DNS server they use) they won't know about it since they don't check DNSSEC themselves. This has the advantage of not ruining someones day because they mis-configured their DNSSEC for the zone they use. If somewebsite.com has bad DNSSEC configs, you won't be able to resolve it, and people will first call the ISP to ask them why they are "blocking" that site. – John Keates Nov 20 '16 at 17:37