4 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

[3] "you tell your registrar your signing key's fingerprint by creating a DS record" http://security.stackexchange.com/a/11571/10863https://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_142626security.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_142604security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

[7] http://security.stackexchange.com/a/11571/10863https://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] http://security.stackexchange.com/a/126518/10863https://security.stackexchange.com/a/126518/10863

[3] "you tell your registrar your signing key's fingerprint by creating a DS record" http://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

[7] http://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] http://security.stackexchange.com/a/126518/10863

[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

[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

3 Added sources; fixed mistakes; clarified a few things.
source | link

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

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.[10][1]

[1] http://security.stackexchange.com/a/11571/10863https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3

[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." http://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." http://security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

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

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

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

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.[10]

[1] http://security.stackexchange.com/a/11571/10863

[4] http://security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] http://security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

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

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

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

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]

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

[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

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

2 Added sources; fixed mistakes; clarified a few things.
source | link

(This response was compiled from other comments, answers and other sources I've read before and since asking the question. Please edit the post if I'm wrong about something! I'll remove this text later, or if you corrected any mistakes (and are sure there are no more mistakes) you can also remove it.)

1. What is the goal of DNSSEC?

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

The root signs keys from TLDs such(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]

It explicitly does not prevent MITM attacksDNSSEC 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 domain does not have DNSSEC enabled (for example because the registrar wasdoes not signed by the TLD)support it, there will never be a signed response. So you will never know whether an attacker stripped the signature or whether DNSSEC was just not enabled. It's similar toif a https handshake failing: you don't know whether the attacker blocked port 443 (forcing you to connect over port 80 via http) or whether the websiteTLD does not have https enabledsupport it, your computer just cannot verify the authenticity of the records of the domain you're querying.

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]

They can'tIf 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 practical attacks does DNSSEC solveif we remove the TLD's signature as well? Nothing really, just that recursive nameservers can't feed you fake informationAlright, knowingly or accidentally. There are just very few scenarios in which casethen the root will tell us (with signature) that would happen without a MITM being present somewherethe TLD should have had it enabled.

People mention DNS cache poisoning, butIf the Kaminsky attack is a fixed issue. Guessing a source portroot is still possible as far as I nowtrustworthy, butand the chances of success are a few in 64500root only signs legitimate TLDs, and you get to retry every time the TTL expires which is between a few hours and a day by default. ThisTLD is not entirely negligible, but if it was an issue it would have been fixed by now. Anyone who wants secure WAN communications uses authenticated encryption such as SSHtrustworthy, TLSand the TLD only signs registrars, Torand the registrar is trustworthy, IPSEC or some VPN anywaythen you can be sure the signed records came directly from the domain owners.

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

The latterDomain 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.[10]

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 Tylerl explained(one character incremented) and it very well inwill 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] this posthttp://security.stackexchange.com/a/11571/10863

[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" http://security.stackexchange.com/a/11571/10863

[4] http://security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] http://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", I'll citebut no RRSIG record in slightly abbreviated form:the reply, something is wrong and maybe a man in the middle attack is going on"

A: "So what if people know what zones exist; DNS is public information. It was never meant to be a secret anyway."

B: "This is a security risk. If I have a server named accounting.example.com, then someone who intrudes on my network can quickly tell which machine has the juicy information on it and therefore which one to attack."

A: "Then don't call it that! If your entire security model is based on the concept of keeping public information secret, then you, sir, are an idiot."

B: "It's not about keeping secrets, it's about not revealing more information than you have to."

And so on.

[7] http://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] http://security.stackexchange.com/a/126518/10863

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

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

(This response was compiled from other comments, answers and other sources I've read before and since asking the question. Please edit the post if I'm wrong about something! I'll remove this text later, or if you corrected any mistakes (and are sure there are no more mistakes) you can also remove it.)

1. What is the goal of DNSSEC?

DNSSEC signs DNS records. 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.

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

It explicitly does not prevent MITM attacks. If a domain does not have DNSSEC enabled (for example because the registrar was not signed by the TLD), there will never be a signed response. So you will never know whether an attacker stripped the signature or whether DNSSEC was just not enabled. It's similar to a https handshake failing: you don't know whether the attacker blocked port 443 (forcing you to connect over port 80 via http) or whether the website does not have https enabled.

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.

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.

They can't.

So what practical attacks does DNSSEC solve? Nothing really, just that recursive nameservers can't feed you fake information, knowingly or accidentally. There are just very few scenarios in which case that would happen without a MITM being present somewhere.

People mention DNS cache poisoning, but the Kaminsky attack is a fixed issue. Guessing a source port is still possible as far as I now, but the chances of success are a few in 64500, and you get to retry every time the TTL expires which is between a few hours and a day by default. This is not entirely negligible, but if it was an issue it would have been fixed by now. Anyone who wants secure WAN communications uses authenticated encryption such as SSH, TLS, Tor, IPSEC or some VPN anyway.

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

The latter is made possible because of the way they solved NXDOMAIN signing. Tylerl explained it very well in this post, I'll cite in slightly abbreviated form:

A: "So what if people know what zones exist; DNS is public information. It was never meant to be a secret anyway."

B: "This is a security risk. If I have a server named accounting.example.com, then someone who intrudes on my network can quickly tell which machine has the juicy information on it and therefore which one to attack."

A: "Then don't call it that! If your entire security model is based on the concept of keeping public information secret, then you, sir, are an idiot."

B: "It's not about keeping secrets, it's about not revealing more information than you have to."

And so on.

1. What is the goal of DNSSEC?

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

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.

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]

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.

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.[10]

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] http://security.stackexchange.com/a/11571/10863

[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" http://security.stackexchange.com/a/11571/10863

[4] http://security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] http://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] http://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] http://security.stackexchange.com/a/126518/10863

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

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

1
source | link