DNSSEC NSEC vs NSEC3 Zone Walking Auditor
Inspect DNSSEC authenticated denial of existence mechanisms. Audit whether your domain uses plain RFC 4034 NSEC (vulnerable to complete zone enumeration) or RFC 5155 NSEC3 hashed denial.
Frequently Asked Questions
What is DNSSEC zone walking and how does it compromise domain privacy?
In RFC 4034 DNSSEC, plain NSEC records prove that a queried record does not exist by returning the names of the alphabetically preceding and succeeding records in the zone. An attacker can repeatedly query non-existent names and walk through the chain, dumping every single subdomain, host, and internal server name in the entire zone.
How does RFC 5155 NSEC3 mitigate zone walking?
NSEC3 replaces cleartext domain names with salted cryptographic SHA-1 hashes of the domain names. Instead of proving that "mail" to "vpn" has no records between them, it proves that Hash(A) to Hash(B) has no records between them, preventing casual alphabetical discovery.
Can NSEC3 zones still be cracked through offline dictionary attacks?
Yes. If an attacker collects the salted hashes from NSEC3 records, they can run offline dictionary wordlists against the salt. Using high iterations once helped, but RFC 9276 now recommends setting iteration count to 0 because high iteration counts consume excessive CPU on validating resolvers (DoSing them) while providing minimal resistance against modern GPU hash cracking.
What are current IETF best practices for authenticated denial of existence?
RFC 9276 recommends using NSEC3 with 0 iterations and a small or empty salt to prevent resolver CPU exhaustion, or adopting "Compact Denial of Existence" / White Lies (RFC 4470) where authoritative servers synthesize minimal NSEC records on the fly.