Zone walking abuses DNSSEC's NSEC records to enumerate every subdomain in a zone.
What is Zone Walking?
Zone walking is an enumeration attack that exploits the authenticated denial of existence mechanisms in DNSSEC to perfectly map and reconstruct every subdomain in a target zone.
When DNSSEC was designed, it needed a way to securely prove that a requested domain name does not exist. Generating cryptographic signatures on-the-fly for every invalid query is computationally expensive and vulnerable to DoS attacks. To solve this, DNSSEC pre-signs the alphabetical "gaps" between existing records using NSEC (Next Secure) records.
Frequently Asked Questions
However, this elegant engineering solution inadvertently created a massive reconnaissance exposure. Attackers realized they could query these gaps continuously to "walk" from one existing record to the next, harvesting an organization's entire internal and external DNS footprint.
How NSEC enables zone walking
Standard NSEC records prove denial of existence by pointing directly to the next valid canonical name in the zone file.
If your zone contains api.example.com and mail.example.com, querying a non-existent subdomain like beta.example.com will return an NSEC record stating, "There are no records between api and mail."
An attacker can exploit this ordered chain of names algorithmically:
They query a.example.com to get the first real record (api.example.com).
They query api0.example.com to get the next real record (mail.example.com).
They repeat this process until the chain loops back to the start, systematically dumping every entry.
Real NSEC record example
Here is what an attacker sees in a raw NSEC response:
DNS Record / Config
api.example.com. 3600 IN NSEC mail.example.com. A AAAA RRSIG NSEC
This single packet explicitly hands the attacker the next valid subdomain (mail.example.com) in plain text, along with the record types associated with api.example.com.
Why attackers want your zone data
Exposing your entire DNS map provides adversaries with a pristine targeting inventory. Attackers are not looking for your public web server; they are looking for the infrastructure you forgot about:
Shadow IT: Unpatched development environments (dev-old-api.example.com) that lack WAF protection or MFA.
Subdomain Takeovers: Dangling CNAMEs pointing to abandoned AWS S3 buckets or Azure resources, ripe for hijacking.
Targeted Phishing: Internal portals (vendor-invoicing.example.com) that provide exact contextual nomenclature for highly convincing social engineering lures.
NSEC3 as the mitigation
To address the severe privacy leak of plain NSEC, the engineering community introduced NSEC3 (RFC 5155).
Instead of returning plain-text hostnames in the gaps, NSEC3 hashes the hostnames (typically using SHA-1) and sorts the hashes. The NSEC3 record then proves there are no hashed names between Hash A and Hash B.
To increase the cryptographic cost for attackers attempting to reverse the hashes, NSEC3 introduced:
Salt: A random string appended before hashing to defeat pre-computed rainbow tables.
Iteration Count: The number of times the hash function is applied, forcing attackers to spend more CPU cycles.
NSEC3 real record example
Here is a raw NSEC3 record covering a cryptographic gap:
DNS Record / Config
1Q7B... 3600 IN NSEC3 1 0 10 1234ABCD 2V8C... A RRSIG
This record indicates that between the hash starting with 1Q7B and the hash starting with 2V8C, no other hashed records exist. The 10 indicates the iteration count, and 1234ABCD is the salt.
Remaining NSEC3 risks
NSEC3 is a mitigation, not a silver bullet. While it prevents trivial, scriptable zone walking, it is highly susceptible to offline dictionary attacks.
Attackers can still send strategic queries to collect the entire ring of NSEC3 hashes. Once collected, they take the hashes offline to powerful GPU cracking rigs. Using massive wordlists of common subdomains (e.g., dev, staging, vpn, gitlab), they hash their dictionary words using the zone's specific salt and iterations. If their calculated hash matches a hash in the NSEC3 ring, the subdomain is exposed.
Important
Deploying NSEC3 with 0 iterations and an empty salt provides nearly zero protection against offline cracking. However, RFC 9276 strongly recommends this configuration because high iterations cripple resolver performance while offering negligible resistance to modern GPUs. Assume your namespace can be discovered.
How to check your zone's NSEC type
You can check whether a domain uses NSEC or NSEC3 using standard dig commands by intentionally querying a subdomain that is unlikely to exist.
To check for NSEC exposure, use the +dnssec flag:
DNS Record / Config
dig non-existent-subdomain.example.com A +dnssec
Review the AUTHORITY SECTION of the response.
If you see NSEC records with plain-text domains, the zone is trivially walkable.
If you see NSEC3 records with long alphanumeric hashes, the zone is using hashed mitigation.
Black lies / aggressive NSEC
To definitively stop zone walking, some modern, highly scalable authoritative DNS providers (like Cloudflare) employ advanced techniques like "Black Lies" or "White Lies" (Dynamic NSEC3).
Instead of pre-signing the entire zone's gaps, these providers dynamically synthesize a mathematically valid, signed NSEC or NSEC3 record on the fly that perfectly matches the requested non-existent name. By claiming the requested non-existent record is the only gap, they completely eliminate the ability to walk the zone, preserving both cryptographic integrity and infrastructure secrecy.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl audits your DNSSEC configuration to verify that NSEC3 is deployed with appropriate opt-out and iteration settings — blocking automated zone enumeration tools that attempt to reconstruct your full subdomain inventory. The platform flags zones still using bare NSEC records and detects NSEC3 configurations with dangerously low iteration counts that remain vulnerable to offline hash-cracking.
Yes, although NSEC3 makes enumeration harder than plain NSEC because names are hashed. It raises the cost of walking the zone, but it does not make discovery impossible in every case. Attackers can still use wordlists, offline cracking against predictable names, and other side channels, especially when the namespace is small or the labels are guessable.
Should I disable DNSSEC to prevent it?
No. Disabling DNSSEC to avoid zone walking is usually the wrong trade. DNSSEC solves a more important integrity problem. The better approach is to use NSEC3 or aggressive denial minimization where appropriate, keep names less guessable, and decide whether the zone reveals more than it should through other public sources such as CT logs anyway.
What is NSEC3 white lies?
“White lies” refers to authoritative-server behavior that synthesizes denial-of-existence responses instead of exposing a neat chain of real names. The goal is to preserve DNSSEC validation while reducing how much an attacker can learn from walking authenticated denial records directly.
Can my registrar configure this?
Sometimes, but only if the registrar or DNS host is also the authoritative DNS provider exposing DNSSEC settings. In many organizations the registrar is not the same party operating the live zone. The first step is to identify who controls authoritative DNS and whether they support the DNSSEC mode you actually want.
What is Zone Walking?
Zone walking abuses DNSSEC's NSEC records to enumerate every subdomain in a zone. In practice, teams care about Zone Walking because it changes a real trust boundary somewhere in the stack and gives them a concrete signal they can validate on the live domain or application.
How many iterations should NSEC3 use?
RFC 9276 strongly recommends 0 iterations and an empty salt. High iteration counts degrade resolver performance significantly while offering minimal protection against modern GPU-based offline cracking.
Can NSEC3 opt-out prevent zone walking?
Opt-out reduces the size of the NSEC3 chain for large registries (like TLDs) by skipping delegations that don't use DNSSEC. It is generally not recommended or useful for standard enterprise zones trying to prevent enumeration.
