6

In DNSSEC, NSEC records are used to provide proof of nonexistence. The trouble is that these records provide pointers to existent domain names (the closest known domain in either direction) constructing a chain that can be "walked" to eventually disclose all domain names in a given zone through further failed queries.

The method as I understand it relies on crafting queries for domains that do not have a corresponding record. Are zones with wildcard DNS records still somehow susceptible to this attack?

  • What are you trying to hide from attackers? – curiousguy Jul 3 '12 at 16:20
  • The information potentially disclosed are domain names. The question however is not how to "best" stop this, but rather whether those zones are still susceptible. Zones with wildcard records are an edge case I am interested in understanding. – chao-mu Jul 3 '12 at 18:19
  • "wildcard DNS" you mean a domain foo.bar such that x.foo.bar returns the same DNS record, for every x ? – curiousguy Jul 4 '12 at 6:31
  • Yes, that is my understanding. So I am searching for a case that even in those conditions, proof of nonexistence is needed. Hence the edginess of the case. – chao-mu Jul 4 '12 at 15:46
  • baz.foo.bar may exist, but what about qux.baz.foo.bar? – curiousguy Jul 4 '12 at 16:01
3

They should still be vulnerable, since the wildcard record is signed as literally "*". The details of how wildcard results are handled are covered in RFC 2535 (DNSSEC), RFC 3845 (NSEC RDATA format), and RFC 5155 (NSEC3 hashed responses).

This simple description was helpful to me in understanding how a wildcard response can be proven: "The receiving nameserver can derive from this that the record 'www.example.com' was synthesised from '*.example.com', and check the signature accordingly."

It is possible that some tools and scripts designed to conduct NSEC-walking would fail in the case of wildcard responses, but this would not prove that the attack is not still possible.

0

If you are worried about attackers walking your zone, you should configure it to use NSEC3 instead of NSEC for denial. This works with wildcard records, which have no bearing on zone walking in either case.

NSEC3 uses hashes of the names to assert the nonexistence of a record. An attacker has no way of obtaining the original names from their hashes, so he does not receive hints pointing to neighboring names in the zone.

As is the case with NSEC, an attacker can still tell that the response is due to the presence of a wildcard record. However, zone walking is possible with NSEC (and impossible with NSEC3) regardless of whether the zone includes wildcard records.

NSEC3 is supported by Windows DNS in Server 2012 (and higher) and BIND 9+. Older versions only supported DNSSEC with NSEC.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.