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

DNS zone walking is a reconnaissance technique that exploits DNSSEC's NSEC (Next Secure) records to systematically enumerate every name in a DNS zone. NSEC records were designed to provide authenticated denial of existence — proof that a queried name does not exist — but their implementation creates a linked chain that reveals all names in the zone. An attacker can follow this chain to discover every subdomain without needing to brute-force or guess names.

This is one of those cases where a security feature (DNSSEC) introduced a new information disclosure vulnerability. Understanding it is important for anyone who has enabled DNSSEC or is considering it.

How NSEC Records Work

When DNSSEC was first designed, it needed a way to prove that a domain name does not exist. Without this, an attacker could forge a "name does not exist" (NXDOMAIN) response and deny access to legitimate domains.

The solution was NSEC records. An NSEC record for a name points to the next existing name in the zone, sorted alphabetically. This creates 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 for a name that does not exist — say bbb.example.com — the authoritative server returns the NSEC record for beta.example.com, which says "the next name after beta is gamma." This proves there is nothing between beta and gamma, so bbb.example.com genuinely does not exist.

The problem is obvious: each NSEC record reveals the next name in the zone. Follow the chain from the beginning, and you discover every name.

How Zone Walking Works

The attack is straightforward:

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

# Start the walk
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

Tools like ldns-walk and nsec3walker automate this process and can enumerate an entire zone in seconds.

The NSEC records also reveal which record types exist for each name (shown after the next name in the NSEC record data). This tells the attacker not just that admin.example.com exists, but that it has A and AAAA records — meaning it is a host with IPv4 and IPv6 addresses.

Why You Cannot Speed This Up With Parallel Queries

If you are writing a zone walking script and thinking about firing off concurrent requests to speed things up — save yourself the trouble. I went down this road and it is a dead end. Zone walking is inherently sequential: each NSEC response reveals the next name in the chain, and you cannot send query N+1 until you have the answer from query N. There is no way to split the walk across threads, guess ahead, or divide the zone into parallel ranges. For most domain zones with hundreds or a few thousand subdomains this is not a real bottleneck anyway — the walk completes in seconds. If you are walking a TLD zone with millions of entries, the sequential constraint is more painful, but the answer is still the same: the walk itself cannot be parallelized.

Real-World Impact

Zone walking has been used to:

• Map corporate infrastructure by discovering internal-sounding subdomains like vpn, staging, jenkins, gitlab, and internal
• Identify attack targets — subdomains running specific services are often more vulnerable than the main domain
• Prepare for subdomain takeover by identifying CNAMEs to third-party services
• Competitive intelligence — discovering product names, internal projects, and infrastructure details from subdomain names

Several large organizations discovered this the hard way after enabling DNSSEC with NSEC and finding their complete subdomain inventory indexed by security researchers and attackers alike.

How Attackers Discover This Weakness

An attacker simply needs to check whether a domain uses NSEC or NSEC3:

dig example.com NSEC +dnssec

If the response includes NSEC records (rather than NSEC3), the zone is walkable. This is a five-second check that reveals a significant information exposure.

NSEC3: A Deterrent, Not a Complete Fix

NSEC3 (defined in RFC 5155) was created to make zone walking harder. Instead of chaining cleartext domain names, NSEC3 chains hashed versions of the names.

# Instead of:  alpha → beta → gamma
# NSEC3 shows: 1abc3f → 4de7a2 → 9bc1d5

The hashes are computed using a salt and multiple iterations, making it computationally expensive to reverse them back to the original names.

NSEC3 makes zone walking significantly harder but not impossible. The hashes can be cracked with enough computational effort and a good dictionary. This is an important distinction — NSEC3 is a deterrent that raises the cost of enumeration, not a guarantee of privacy. Here is why:

• Offline dictionary attacks work because the NSEC3 hash algorithm, salt, and iteration count are all public (they are in the NSEC3PARAM record). An attacker downloads the hashed chain, then hashes a dictionary of common names (www, mail, api, staging, vpn, admin) against the known parameters. Any match reveals a real subdomain.
• GPU-accelerated cracking has made this even more practical. Tools like nsec3map and hashcat can test millions of candidate names per second against NSEC3 hashes.
• Rainbow table attacks are possible if the salt is short or the iteration count is low.
• The opt-out flag in NSEC3 means unsigned delegations may not have corresponding NSEC3 records, potentially leaking information about the zone structure.

The bottom line: if your subdomains use predictable names, NSEC3 will not protect them from a motivated attacker. It stops casual automated walking, but it does not stop targeted enumeration.

How to Test Your Own Domain

Check whether your domain uses NSEC or NSEC3:

# Query for a name that does not exist
dig nonexistent.example.com A +dnssec

# Look for NSEC or NSEC3 records in the authority section

If you see NSEC records with cleartext names, your zone is walkable. If you see NSEC3 records with hashed values, you are using the safer variant.

Attempt a zone walk on your own domain:

# If you have ldns-utils installed
ldns-walk example.com

If this returns a list of your subdomains, you need to switch to NSEC3.

You can also use the DNS Inspector to examine your domain's DNSSEC configuration and record types.

How to Defend Against It

Switch from NSEC to NSEC3

This is the primary mitigation. Most DNSSEC-capable DNS software supports NSEC3:

# BIND example: generate NSEC3 parameters
rndc signing -nsec3param 1 0 10 auto example.com

Use Strong NSEC3 Parameters

• Use a random salt (at least 8 characters)
• Use a sufficient iteration count (the balance is between security and performance; 10-20 iterations is common)
• Rotate the salt periodically

Consider Whether You Need DNSSEC

For internal zones or zones where subdomain privacy is critical, weigh the benefits of DNSSEC against the information disclosure risk. If zone walking is a greater concern than cache poisoning for your specific use case, you may decide DNSSEC is not appropriate for that zone.

Mitigation Checklist

• Zones use NSEC3 instead of NSEC
• NSEC3 salt is random and sufficiently long
• NSEC3 iteration count is appropriate for your zone size
• NSEC3 salt is rotated periodically
• Subdomain naming conventions avoid revealing sensitive information
• Zone walking tests are included in security audits

Common Misconfigurations

• Enabling DNSSEC with default NSEC without switching to NSEC3
• Using an empty or trivially short NSEC3 salt, making dictionary attacks easier
• Setting iteration count to zero, removing the computational cost of cracking hashes
• Never testing your own zone for walkability after enabling DNSSEC

Ethical Note

Zone walking against domains you do not own exists in a legal gray area. The records are technically public (DNSSEC is designed to be verifiable by anyone), but using the information for unauthorized purposes is not. Only perform zone walking against your own domains or with explicit authorization. For practice, sign a test zone in a lab environment 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.