7

According to Wikipedia:

DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an attacker to map network hosts or other resources by enumerating the contents of a zone.

Most of the TLDs have adopted DNSSEC. Does the problem described above still exists? How can that be checked (e.g. Linux command)?

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
lepe
  • 2,184
  • 2
  • 15
  • 29
  • Related: http://security.stackexchange.com/questions/11621/how-can-i-tell-if-a-dnssec-zone-is-protected-using-nsec3-versus-nsec – lepe Jul 21 '15 at 02:01
  • Related: http://security.stackexchange.com/questions/11566/how-does-dnssec-work-are-there-known-limitations-or-issues – lepe Jul 21 '15 at 02:01

1 Answers1

5

First, I will point out that private information should not be posted in the public domain name system. However, for the obscure case this is actually needed DNSSEC now supports NSEC3 for zones, which prevents this kind of attack (Although is more expensive on the DNS query from my understanding of how NSEC3 works compared to plain NSEC).

Edit: Didn't see the date on this question, hope my answer helps someone.

Edit2: Do note that as @kasperd points out below, this setup is still vulnerable to an offline brute force attack. Read the comments below for more information.

ConnorJC
  • 326
  • 2
  • 6
  • There is nothing wrong with posting a late answer to an old question without one (or where you can add something to existing answers). In fact, that is encouraged. So no need to worry about the date on the question. – Anders Jun 08 '16 at 22:47
  • 1
    NSEC3 only provides a partial solution though. It still permits enumeration of all the NSEC3 records after which an offline brute force attack can be mounted against those records to recover the original names. (Don't worry about the date on the question. Open questions with no answers are kept around such that they can be answered eventually. So answering this question is entirely within the spirit of the site.) – kasperd Jun 08 '16 at 22:48
  • @kasperd That is true, although there really isn't a way to stop brute force attacks, as they can be mounted against live non-DNSSEC servers with some effort as well. – ConnorJC Jun 08 '16 at 22:51
  • 1
    @ConnorJC Online attacks can be rate-limited. Had NSEC3 been designed slightly different, it could have prevented offline attacks. But I agree that anything put in DNS records should be assumed to be publicly available. – kasperd Jun 08 '16 at 22:58
  • @kasperd How could NSEC3 have been designed to prevent an offline attack, as the data must be verified essentially 'offline'? – ConnorJC Jun 08 '16 at 22:59
  • @ConnorJC Instead of an iterated hash, it could have done hash-sign-hash - with a signature key only kept on the server side. In other words keep only the first and last iteration of the hash and replace all the intermediate hashing steps with a single signature computation. Obviously the key-pair used for that signature must not be one used anywhere else. During legitimate lookups the authoritative DNS server has to perform one signing step, and it would have to send one additional record with the signature for the client (or recursor) to verify. – kasperd Jun 08 '16 at 23:09
  • @kasperd I'm not sure I fully understand this, but I think it's still weak to an offline attack. If the server signs the initial hash, than it must provide the signature, as the client cannot generate it on its own (It doesn't have the private key). If that's the case, can't an offline attacker just keep hashing until (s)he finds the hash the signature signs? – ConnorJC Jun 08 '16 at 23:14
  • @ConnorJC In the scheme I proposed, the signature the server sends to the client will always be on the name just requested by the client. So the client will only ever see signatures on names it already knows. The values in the "NSEC4" records would be hashes of signatures. And those cannot be brute forced by the client. In order to verify the connection between a name and a hash, the attacker would have to compute an unknown intermediate step by either forging a signature or inverting a cryptographic hash. – kasperd Jun 08 '16 at 23:19
  • @kasperd Ah, but this requires the DNS server to sign requests dynamically, which is intentionally avoided in the current NSEC/NSEC3 spec. This makes DOS attacks significantly easier, and requires the key be attached to the live DNS server, which are two things the authors of NSEC/NSEC3 wanted to avoid. **Edit:** Also, this makes DNS caching significantly less effective. – ConnorJC Jun 08 '16 at 23:24
  • @ConnorJC NSEC3 uses an *iterated* hash. That is deliberately slow. The scheme I proposed would replace that slow computation with a different equally slow computation, which provides more security than the iterated hash. So the only thing you lose is the flexibility in choosing an iteration count. As for needing the key online, that is why I pointed out that it has to be a key not used for any other purpose. Should that secret key leak the only consequence would be that the contents of your zone leaked, but the contents of your zone has to be stored on the authoritative server anyway. – kasperd Jun 08 '16 at 23:35
  • @kasperd From what I understand of your previous comments, you would sign the domain that was **requested**. NSEC3 doesn't do any hashing on the request, all of its hashes/signatures can be (and are) computed in advance. However, with your scheme the signing has to take place during the request, which slows down the request in a way NSEC3 doesn't. – ConnorJC Jun 08 '16 at 23:38
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/40919/discussion-between-kasperd-and-connorjc). – kasperd Jun 08 '16 at 23:39