DNS Zone Walking for Subdomain Enumeration: How NSEC Exposes Your Subdomains

DNS zone walking uses DNSSEC's NSEC records to enumerate every name in a zone. NSEC exists to prove that a name does not exist, but it provides that proof by pointing at the names that do, forming a chain an attacker can follow. Applied to an organization's zone, it returns the full subdomain inventory without a single guess or brute-force attempt.

The mitigation most guides recommend, switching to NSEC3, raises the cost without removing the exposure. The mechanism that genuinely prevents enumeration is online signing with minimally covering NSEC records, covered below.

How NSEC Records Work

DNSSEC needed a way to prove a name does not exist, using records signed in advance. Without it, an attacker could forge a "name does not exist" (NXDOMAIN) response and deny access to legitimate domains.

NSEC provides this by pointing each name at the next existing name in the zone, in canonical order. The result is a chain:

alpha.example.com → NSEC → beta.example.com
beta.example.com  → NSEC → gamma.example.com
gamma.example.com → NSEC → alpha.example.com (wraps around)

When a resolver queries a name that does not exist, say delta.example.com, the server returns the NSEC record for beta.example.com stating that the next name after beta is gamma. Since delta sorts after beta and before gamma, nothing can exist in that gap, so delta.example.com is proven absent.

The ordering is DNSSEC canonical order, defined in RFC 4034 Section 6.1: names compared label by label, right to left, each label compared as lowercase octets. It rewards care. bbb.example.com sorts before beta.example.com, since comparing the leftmost labels the second octet b precedes e. A beta to gamma record proves nothing about bbb.

Every negative answer therefore discloses two real names. Follow the chain and you have the zone.

How Zone Walking Works

1. Query the zone apex: dig example.com NSEC
2. The response names the next entry, say admin.example.com
3. Query admin.example.com NSEC
4. The response names the next entry: api.example.com
5. Continue until the chain wraps to the beginning

dig example.com NSEC +short
# Returns: admin.example.com A AAAA RRSIG NSEC

dig admin.example.com NSEC +short
# Returns: api.example.com A RRSIG NSEC

dig api.example.com NSEC +short
# Returns: blog.example.com CNAME RRSIG NSEC

ldns-walk, dnsrecon, amass, and Nmap's dns-nsec-enum and dns-nsec3-enum scripts automate this and enumerate a typical zone in seconds.

NSEC records also list which record types exist for each name, shown after the next name in the record data. That tells an attacker not only that admin.example.com exists, but that it has A and AAAA records and is therefore a live host on IPv4 and IPv6.

Keep this in proportion. Certificate transparency logs and passive DNS expose much of the same information for any host that has been issued a TLS certificate, without touching your nameservers at all. Zone walking is one enumeration channel among several, and often not the most productive one.

Walking Is Parallelizable

A walk is not restricted to one name at a time, despite each NSEC record pointing only at the next.

You do not need a real name to begin. Query any name that does not exist, and the denial-of-existence proof must return the NSEC record covering that gap, naming the real entries on both sides:

dig +dnssec nonexistent-test-domain.se

# Authority section contains:
# nonetype.se.  7200  IN  NSEC  nonezero.se. NS RRSIG NSEC

Two real names from one query about a name that was never registered. Pick many random starting points, walk each concurrently, and let the partial chains grow into one another until they merge into the full ordering. Tools such as n3map are built on this design.

For a single organization's zone of a few hundred subdomains this is academic, since the walk completes in seconds regardless. It matters when walking a TLD zone.

Real-World Impact

Zone walking has been used to:

• Map corporate infrastructure through internal-sounding subdomains such as vpn, staging, jenkins, gitlab, and internal
• Identify attack targets: subdomains running specific services are frequently weaker than the main domain
• Prepare subdomain takeovers by locating CNAMEs pointing at third-party services
• Gather competitive intelligence: product names, internal projects, and infrastructure details are often legible from subdomain names alone

Organizations have repeatedly discovered this after enabling DNSSEC with NSEC and finding their complete subdomain inventory indexed by researchers and attackers alike.

Checking for the exposure takes one command:

dig example.com NSEC +dnssec

NSEC records in the response rather than NSEC3 mean the zone is walkable.

NSEC3 Raises the Cost, It Does Not Close the Exposure

NSEC3 (RFC 5155) chains hashed names instead of cleartext ones:

# NSEC:  alpha → beta → gamma
# NSEC3: 1abc3f → 4de7a2 → 9bc1d5

Hashes are computed with SHA-1, optionally with a salt and additional iterations. The intent was to make reversal expensive. Against modern cracking hardware and predictable naming, it is not, and current guidance is to use no salt and no extra iterations at all.

NSEC3 converts instant enumeration into an offline cracking problem. For a typical corporate zone, that problem is easy:

• Offline dictionary attacks work because the algorithm, salt, and iteration count are published in the NSEC3PARAM record. An attacker collects the hashed chain, then hashes candidates (www, mail, api, staging, vpn, admin) against the known parameters. Matches reveal real subdomains.
• GPU acceleration makes this routine. n3map and hashcat test millions of candidates per second.
• Subdomain names are unusually guessable. Organizations converge on the same conventions, so a few thousand common labels recover most of a typical zone.

If your subdomains use predictable names, NSEC3 will not protect them. It stops casual automated walking and does not stop targeted enumeration.

Opt-Out Does Not Transfer From TLDs to Ordinary Zones

The NSEC3 opt-out flag is what constrains enumeration of large TLD zones, and it helps far less here. Opt-out can only omit insecure delegations, meaning child zones delegated away without a DS record. It cannot omit ordinary host records, which is what most organizational zones consist of, so www, vpn, staging, and jenkins remain chained regardless.

Where a zone does contain many unsigned delegations, such as a large tenant or customer namespace, opt-out excludes those delegation names and is worth considering. RFC 9276 Section 3.1 treats this as a question of whether a zone is large and delegation-heavy, not whether it is a TLD.

Testing Your Own Zone

Identify the scheme:

dig nonexistent.example.com A +dnssec
# Look for NSEC or NSEC3 records in the authority section

Attempt the walk:

ldns-walk example.com

A returned list of subdomains means the zone is enumerable.

Whether that constitutes a problem is a decision to make explicitly rather than by default. Many operators run NSEC knowingly, because their subdomain names are not sensitive and equivalent information leaks through certificate transparency anyway. Others treat an enumerable zone as unacceptable. The defences below are ordered by how much they actually deliver.

The DNS Inspector shows DNSSEC configuration and record types for any domain.

How to Defend Against It

Online Signing With Minimally Covering NSEC

This is the mitigation that prevents enumeration rather than repricing it. RFC 4470 specifies on-the-fly minimally covering NSEC records, commonly called "white lies," with Cloudflare's variant known as "black lies."

Rather than precomputing a chain across real zone contents, the nameserver signs each negative answer at query time, returning a range just wide enough to cover the queried name and nothing else. No chain links one real name to another, so there is nothing to follow and nothing to collect.

# Conventional NSEC: discloses a real neighbouring name
admin.example.com  NSEC  api.example.com

# White lie: synthesized range bracketing only the queried name
# A query for nonexistent.example.com returns a range like
# nonexistemu.example.com  NSEC  nonexistent0.example.com

Black lies go further, answering NXDOMAIN queries as NODATA, which shrinks the response and avoids a second NSEC record.

The tradeoff is that every negative answer requires an online signing operation, so the private key lives on the responding server rather than offline in a signer. That suits managed DNS providers and often rules it out for organizations signing their own zones offline. Cloudflare, Route 53, and NS1 all offer it, so for most operators the practical route is choosing a provider that signs live rather than tuning NSEC3 parameters.

Use Unpredictable Names for Sensitive Hosts

Cracking is the real threat model for NSEC3, which makes naming the mitigation with the best return. A host called jenkins or staging falls to any wordlist. One carrying a random component does not, whether or not the zone is walkable.

If You Use NSEC3, Use RFC 9276 Parameters

Most DNSSEC-capable software supports NSEC3. RFC 9276 specifies zero extra iterations and an empty salt:

# BIND: NSEC3, zero extra iterations, no salt
rndc signing -nsec3param 1 0 0 - example.com

Advice recommending a long random salt, 10 to 20 iterations, and periodic rotation predates RFC 9276 and no longer applies:

• A salt adds no security here. Salts defend against tables precomputed in advance and reused across many targets. An attacker walking your zone reads the salt from NSEC3PARAM and folds it into their hashing, leaving their cost identical. Rotation forces a resign and gains nothing.
• Iterations cost you more than the attacker. Every extra iteration is paid by every validating resolver on every negative answer, permanently. The attacker pays it once per candidate on hardware chosen for the task. High iteration counts are closer to a self-inflicted denial-of-service risk than a defence, which is why RFC 9276 drove the recommendation to zero.

Every major TLD using NSEC3 publishes 1 0 0 -. Some large TLDs, .se among them, use plain NSEC and publish no NSEC3 parameters at all.

For Small Zones, NSEC May Beat NSEC3

CZ.NIC argues at length that small zones should prefer plain NSEC over NSEC3. NSEC3 does not prevent enumeration of a zone with guessable names, while its hashing imposes real CPU cost on validating resolvers, contributing to the resolver-exhaustion problems behind the "NSEC3 close encounter" vulnerability class (CVE-2023-50868).

On that reading, NSEC3 on a small zone purchases illusory privacy at a measurable performance cost. The coherent choices are plain NSEC where enumeration is acceptable, or online signing where it is not.

Consider Whether DNSSEC Fits This Zone

For internal zones where subdomain confidentiality is critical, weigh DNSSEC's benefits against the disclosure. Where zone walking is a greater concern than cache poisoning for a specific zone, DNSSEC may not be the right fit for it.

Mitigation Checklist

• You have made an explicit decision about whether this zone's contents need to be non-enumerable
• If they must not be enumerable, the zone is served by a provider doing online signing with minimally covering NSEC (white lies or black lies)
• Sensitive hosts avoid guessable labels, which is what actually defeats hash cracking
• If NSEC3 is used, it uses zero extra iterations and an empty salt, per RFC 9276
• Subdomain naming conventions avoid revealing sensitive information
• Zone walking tests are included in security audits

Common Misconfigurations

• Treating NSEC3 as a fix rather than a speed bump, and continuing to use guessable names for sensitive hosts
• Using a long salt and a high iteration count, which slows every validating resolver without meaningfully slowing an attacker
• Rotating the NSEC3 salt on a schedule, forcing zone resigns for no security benefit
• Enabling DNSSEC with NSEC without deciding whether an enumerable zone is acceptable
• Never testing your own zone for walkability after enabling DNSSEC

Ethical Note

Zone walking against domains you do not own sits in a legal gray area. The records are public by design, since DNSSEC is built for anyone to verify, but using the information for unauthorized purposes is not. Walk only your own domains or those you have explicit authorization to test. For practice, sign a test zone in a lab and walk it yourself.

This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Zone Walking at the TLD Level, DNS Zone Transfer Attack.