30

Based on information from this site, DNSSec is needed to protect us from a number of DNS and SSL / TLS hacks, including:

I haven't yet seen a good explanation of how DNSSec works outside of the RFC's, so:

  1. How does DNSSec work?
  2. Are there known limitations I should be aware of? Specifically, how to we prevent the case where a MITM hides the "secure" records from being seen on the client, and the client uses insecure DNS? (a variant of this hack)
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

3 Answers3

32

DNSSec is normal DNS, but with signatures. It absolutely prevents DNS Spoofing; that's what it's for, and that's what it does.

Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.

DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing.

How it works

In essence, you tell your registrar your signing key's fingerprint by creating a DS record, and that information will be available from your TLD signed by an upstream key which chains in a like manner all the way to a single globally trusted key.

With this set up, your key is now considered to be the trusted authority for your domain, and is allowed to sign your DNS records. So now for each record in your zone, you create a corresponding RRSIG record which contains the associated digital signature.

Now, when someone looks up a domain in your zone, you can send not only the response, you can also send the corresponding RRSIG record as well which shows that the response was signed by you. To verify the signature, the client fetches your DNSKEY record which contains your full public key, and then just follows normal cryptographic signature verification techniques.

Obviously the DNSKEY record also has its own corresponding RRSIG record so that you can verify that it hasn't been tampered with. But more importantly, there is a DS record available from your parent zone (remember, you gave it to your registrar in the first paragraph) which contains enough information about your public key to verify that your DNSKEY record is actually authorized for your zone.

That DS record is, in turn, singed by your parent's DNSKEY, for which there is a corresponding DS record in the root zone. This way, all key signatures can be traced back to a single trusted source.

Problems

The complication comes when you need to tell someone that a record doesn't exist. Obviously that response needs to be signed, but generally the DNS server itself doesn't have access to your signing key and can't sign the response on-the-fly; the signatures are all created "offline" ahead of time. This keeps your key from being exposed if your DNS server gets compromised.

So instead, you alphabetize your subdomains and say "for every name between mail.example.com and pop.example.com, no other subdomains exist" and sign that assertion. Then when someone asks for nachos.example.com you can just give them that response (which has already been signed) and the client knows that because nachos.example.com falls alphabetically between mail.example.com and pop.example.com, then the "this domain doesn't exist" response is considered to be correctly signed and actually came from you.

The place where this becomes problematic is that by having a set of these negative responses which explicitly state that "no responses exist between X and Y, you can easily map out exactly which domains exist for the entire zone. You know that "X" exists, and you know that "Y" exists, and you know there is nothing else between them. Just do a little more poking at random and you'll quickly be able to compile a list of all the records that do exist.

Controversy

There are two camps in the DNS world with respect to whether or not this is a problem. The first group says:
"So what if people know what zones exist; DNS is public information. It was never meant to be a secret anyway."

To which the second group says:
"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."

To which the first group then replies:
"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."

To which the second group replies:
"It's not about keeping secrets, it's about not revealing more information than you have to."

And so on, ad nauseam.

DNS (and DNSSec) was designed largely by folks in the first camp; DNS is public, therefore being able to map out which subdomains exist in a domain isn't a significant security concern. And anyway, you can't really do signed negative responses any other way.

On the other hand, the servers tend to be run by people in the second camp. They're concerned about the safety of their own network, and they don't want to be giving away any more information than necessary, since they know that all information will eventually be used against them.

So you have a protocol is cryptographically sound and perfectly functional, but which real-world admins tend to be hesitant to implement.

We'll all get there eventually, I imagine. After all, DNS spoofing is more of a real-world concern than any dangers raised by mapping out subdomains. But change takes convincing. So here we are... still.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 2
    Does NSEC3 prevent the zone walking you describe? – makerofthings7 Feb 12 '12 at 15:58
  • NSEC3 was created specifically for that purpose. – tylerl Feb 12 '12 at 16:30
  • But nothing, including NSEC3, can completely keep DNS names a secret, so don't expect them to be. See e.g. [How can I tell if a DNSSec zone is protected using NSEC3 (versus NSEC)](http://security.stackexchange.com/questions/11621/how-can-i-tell-if-a-dnssec-zone-is-protected-using-nsec3-versus-nsec) – nealmcb Feb 14 '12 at 05:22
  • With vanilla DNS one can also easily probe for common hostnames like "accounting". NSEC3 only makes the process somewhat faster. – Sandman4 Jun 24 '12 at 12:02
  • 1
    Couldn't you instead make a hash of each of your domains (SHA or other non-broken algorithm), then sign a certificate saying there are no domains who have hashes between E933AA and F2BADE? The browser requests pop.example.com (which hashes to E933AA) and gets a signed result. They can request nachos.example.com (which hashes to F10000), and that hash is between the two valid ones, so they get a signed negative response. But they don't know what the two end hashes resolve to and would have to brute-force the hashes to figure out the domain. – Stephen Schrauger Aug 04 '14 at 15:32
  • @StephenSchrauger that would be possible, but it would require that the signing key be present on the DNS server. The protocol is designed intentionally such that signing happens offline and no sensitive information be present on the server. This is a main difference between DNSSEC and dnscurve, and is why DNSSEC is on the root servers while dnscurve never will be. – tylerl Aug 04 '14 at 16:28
  • @tylerl but it wouldn't need to have the private key. All it would have is a certificate for each domain and a certificate for each range between. But instead of the range being the alphabetic range of the domains, it would be the integer range of the simple hash of the domains. My comment was in regards to the controversy of revealing all domain names using the signed certificates of alphabetical ranges. – Stephen Schrauger Aug 04 '14 at 17:41
  • @StephenSchrauger ah, i misunderstood your comment. Yeah, i think that would be possible. – tylerl Aug 04 '14 at 17:46
  • I just realized that NSEC3 was exactly what my question was about. The NSEC3 algorithm uses hashes, as tylerl and makerofthing7 pointed out. – Stephen Schrauger Jan 27 '15 at 17:47
  • What about downgrade attacks? A MITM can still spoof DNS by telling you that the record you're requesting isn't a record secured by DNSSEC, right? – Ajedi32 Feb 23 '15 at 15:44
  • @Ajedi32 records signatures can be traced to the root. Since the root servers ARE signed, and since everyone knows that they are, then you'd either have to convince the client that suddenly they are not, or forge a signature to say that something along the chain isn't. – tylerl Feb 24 '15 at 04:57
  • 2
    @tylerl Maybe I'm misunderstanding, but isn't that assuming the attacker is trying to forge a signed record? I'm talking about a downgrade attack, where the MITM just says "Hey client, there is no DNS signature for this record. This record doesn't support DNSSEC. Here's the plain old unsigned DNS record that I modified to say whatever I want." How would the client know that the record was supposed to be signed in the first place? – Ajedi32 Feb 24 '15 at 14:47
  • @Ajedi32 that depends on where in the "middle" the attacker is positioned. If between you and your recursive DNS server (ISP / OpenDNS / etc) or between the recursive DNS server and the root DNS server then yes, then an attacker can theoretically forge the entire chain. I think however what tylerl is saying is that your client will probably remember(cache) / know(have hard-coded information) that the root and TLD servers are signed, so that won't work. – Ohad Schneider Oct 03 '17 at 14:59
  • Of course, any interception lower in the hierarchy (like the domain's name server) won't do the attacker much good, because at that point in the chain the necessity of signing will have already been established: https://security.stackexchange.com/a/56570/73556. – Ohad Schneider Oct 03 '17 at 15:02
  • @OhadSchneider So you're saying is that if a TLD supports DNSSEC, then _all_ domains under that TLD must also support DNSSEC, and the client will enforce that? – Ajedi32 Oct 03 '17 at 15:37
  • 2
    @Ajedi32 no, I'm saying that if a domain that *doesn't* support DNSSEC is under a TLD that *does* support DNSSEC, then the former will sign/prove the fact that the latter does not support it. And it works like that so that a MITM trying to strip the DNSSEC headers from the domain DNS query would have to provide the same proof, which he would not be able to do without the TLD/root private key. – Ohad Schneider Oct 03 '17 at 16:40
1

You should probably read "Against DNSSEC" by Thomas Ptacek and its FAQ.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
0

In terms of deployment issues there are a few "Gotchas":

  1. Zone re-signing:

    DNSSEC uses 2 keys:

    • a key signing key (KSK), usually a long (2048 bits) key for enhanced security, and
    • a zone signing key (ZSK) that is shorter for better performance.

    Since the ZSK is shorter, it needs to be periodically changed, which means re-signing your zones.

    Some of the older DNSSEC tutorials just tell you to sign your zone and don't tell you that you need to regularly re-sign it, which usually results in your zone having invalid signatures after a week.

    Modern authoritative name servers have built in support for generating a new ZSK and re-signing zones. But the ones shipping with current distros may not do.

    Personally I use ZKT for re-signing my zones; it's fine for small setups.

  2. Authoritative Name servers and validating resolvers cannot share an IP address.

    Authoritative name servers set the AA flag ("Authoritative Answer"), but validating resolvers set the AD flag ("AuthenticateD"), these flags are mutually exclusive. If you have any name servers that run in "hybrid" mode—meaning they do both recursion and serve zones for which they are authoritative—then they will have to be split into the two different functions.

  3. Not all registrars support publishing DS records to the root.

    This isn't that big a deal since you can use the ISC's DLV service. Beware of EasyDNS; they support signing zones on their own nameservers but don't do anything with the DS records, which makes their DNSSEC support a bit useless.

Michael
  • 2,391
  • 2
  • 19
  • 36
JasperWallace
  • 446
  • 3
  • 5
  • "DNSSEC uses 2 keys:" May use 2 keys. CErtainly not hardcoded in the protocol. `UK` uses only one. – Patrick Mevzek Jun 17 '20 at 19:44
  • "Not all registrars support publishing DS records to the root." At least in gTLD they are required by their ICANN contract to be able to do that. And `DLV` is now gone. It wasn't really created because of registrars, but more because of TLDs/the root not being signed. The root and most major TLDs are signed now. – Patrick Mevzek Jun 17 '20 at 19:46