DNS Zone Walking at the TLD Level: NSEC, NSEC3, and Coverage Limits

DNS zone walking exploits DNSSEC's denial-of-existence records to enumerate the names in a DNS zone. Applied to a TLD zone such as .com, .se, or .nl, it becomes a way to discover second-level domain registrations directly from the DNS, without registry cooperation and without zone file access.

A walk’s coverage depends on the denial-of-existence mechanism and the names included in its chain. NSEC3 opt-out permits omission of insecure delegations; it does not require every insecure delegation to be absent. The historical July 2026 dataset reported 7,762,604 DS-bearing .com delegations out of 172,738,866 (about 4.5%). That is a parent-DS ratio, not a measured ceiling on a complete .com walk. The extraction manifest and chain-coverage measurement are not published with this article.

While zone walking for subdomain enumeration targets a single organization's zone, TLD zone walking targets the registry itself.

How TLD Zone Walking Works

DNSSEC has to prove that a name does not exist, and it has to do so with records signed in advance. NSEC solves this by pointing each existing name at the next existing name in canonical order. Proving a gap therefore means disclosing the two real names that bracket it.

That is the whole vulnerability. Every negative answer is a small, signed disclosure of two delegated names.

1. Query any name that does not exist under the TLD
2. The authoritative server returns the NSEC record covering the gap, naming the existing name before it and the existing name after it
3. Query a name just past that second name
4. Repeat, collecting names as you go

You do not need to start at the zone apex, and you do not need to know a single real domain to begin. Any nonexistent name gives a foothold. Against .se, which is signed with plain NSEC:

dig +dnssec nonexistent-test-domain.se

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

A negative query can disclose neighboring names represented in the zone; it does not establish their registration history.

Walking Is Parallelizable

A walk is not a strictly sequential process, despite each NSEC record pointing only at the next one.

Since any nonexistent name is a valid entry point, you can generate a few hundred random names, start an independent walk from each, and run them concurrently. Each produces a partial chain. As the walks progress, those fragments run into one another and link up, and you reassemble them into the full ordering. The operation is throughput-bound rather than latency-bound, and tools such as n3map are built around this design.

Query concurrency is therefore not the limiting factor on a TLD walk. Chain size is, and chain size is set by opt-out.

Which TLDs Are Exposed

There are three tiers, and the distance between them is far larger than the distance between a good wordlist and a bad one.

Plain NSEC

Some registries sign with plain NSEC. These zones are completely walkable: every represented delegated name appears in cleartext, with no hashing and nothing to crack. .se is the largest well-known example at roughly 1.4 million domains.

# Check whether a TLD uses NSEC
dig +dnssec nonexistent-test-domain.se

# Readable domain names in the authority section
# means the zone is walkable directly

This is a deliberate registry choice, not an oversight. Several of these registries publish zone data through other channels anyway, so an enumerable chain withholds nothing they intended to keep.

NSEC3

Most large TLDs, including .com, .net, .org, and many ccTLDs, use NSEC3. It replaces cleartext names in the chain with SHA-1 hashes:

# NSEC:  aardvark.example → abbey.example → ability.example
# NSEC3: 1a2b3c4d → 5e6f7a8b → 9c0d1e2f

The hashing is not a secret operation. The algorithm, salt, and iteration count are published in the zone's NSEC3PARAM record:

dig +short NSEC3PARAM com
# Returns: 1 0 0 -
# Algorithm=1 (SHA-1), Flags=0, Iterations=0, Salt=- (empty)

.net, .eu, and .nl return the same values. Zero iterations with an empty salt is current best practice rather than a weakness, for reasons covered under mitigation below.

Opt-Out and the Limits of Coverage Estimates

NSEC3 has an opt-out flag. When set, the signer may leave delegations that are not DNSSEC-signed out of the chain entirely. RFC 5155 permits this omission rather than mandating it, so the flag alone does not prove every unsigned delegation is absent. In practice large registries run signers that do omit them, since keeping the signed zone small is precisely why they enabled opt-out.

A name that was never chained cannot be recovered. There is no hash to attack.

The flag is readable from any live NSEC3 record, as the second field:

dig +dnssec +norecurse nx-probe-9q7z2x.com @a.gtld-servers.net | grep NSEC3
# ... IN NSEC3 1 1 0 - ...
#              ^ ^
#              | +-- flags = 1, opt-out ENABLED
#              +---- algorithm = 1 (SHA-1)

An opt-out range may omit insecure delegations. To measure coverage, inspect the actual chain and its inclusion policy; DS counts alone cannot tell you which insecure delegations were omitted. The apex and other required names also affect chain size.

Historical reported zone counts, July 2026. These figures have not been reconstructed for this update and measure parent DS presence, not successful DNSSEC validation or recovered chain coverage:

The .com row does not establish a 5% recovery ceiling. A complete assessment needs the actual chain, opt-out ranges, included insecure delegations, and the success rate of recovering hashed labels.

Where the 50-80% Figure Comes From

Recovery rates in the 50-80% range circulate widely and describe something real, just not what they are usually applied to.

Wander, Schwittmann, Boelmann and Weis reported recovering 64% of DNSSEC-signed .com names in 4.5 days in GPU-Based NSEC3 Hash Breaking (IEEE NCA 2014). That result belongs to their 2014 corpus and hardware. Multiplying it by this article’s 2026 parent-DS ratio would combine different populations and would not measure current zone recovery.

Keep two quantities separate:

1. The share of collected hashes a dictionary can crack
2. The share of the zone those hashes represented to begin with

For an opt-out TLD, chain membership can substantially limit recovery. Its size must be measured rather than inferred directly from the parent-DS count.

Chain Membership and Name Recovery Are Separate Limits

Two constraints govern a walk, and only one of them concerns cracking.

What lands in the chain. Opt-out decides this. Omitted names are unrecoverable by any amount of compute.

What converts back into a name. NSEC yields cleartext directly. NSEC3 yields hashes, and a hash becomes a domain name only when the input is guessed.

This distinction matters for zones without opt-out. .nl places its entire registry in the chain, so a hash exists for every domain, but collecting hashes is not the same as recovering names. High-entropy or unusual labels may never fall to a wordlist. Full chain representation and full registry recovery are different claims.

Plain NSEC zones such as .se are the true worst case, since no hashing step exists and names arrive readable. Both .se and .nl are registries with high DNSSEC adoption, which is why opt-out would save them little and they skip it.

Why This Matters

• Registry enumeration: under NSEC or NSEC3 without opt-out, represented delegated names can be enumerated in cleartext with NSEC, or recovered from NSEC3 hashes only when guesses succeed
• Brand and trademark intelligence: unreleased product names and defensive registrations become discoverable
• Competitive intelligence: domains registered ahead of a launch are visible before announcement
• Phishing and typosquatting analysis: domains resembling a target can be enumerated for monitoring or takedown
• Market research: registration trends and naming patterns within a TLD become measurable
• Attack surface mapping: discovered domains can be resolved and probed for weaknesses such as hijackable nameserver delegations or dangling records enabling subdomain takeover

Zone walking is one of several ways DNSSEC's own machinery can be turned against a zone. Another is the DNSSEC downgrade attack, which strips signatures to defeat validation outright.

Tools

NSEC Zones

# ldns-walk (part of ldns)
ldns-walk se

dnsrecon, amass, and Nmap's dns-nsec-enum script also perform NSEC enumeration.

NSEC3 Zones

n3map collects the chain and ships separate converters producing John the Ripper or hashcat input. --aggressive controls query concurrency, and johnify and hashcatify are not interchangeable:

# Collect the NSEC3 chain with 16 concurrent queries
n3map -3pvo example-tld.zone --aggressive 16 example-tld

# For hashcat
n3map-hashcatify example-tld.zone example-tld.hashcat
hashcat -m 8300 example-tld.hashcat wordlist.txt

# For John the Ripper
n3map-johnify example-tld.zone example-tld.john

n3map outputs collected NSEC3 records rather than a bare hash list, which is why the converters exist. Nmap's dns-nsec3-enum script performs a smaller-scale equivalent. Verify flags against current tool documentation, as these CLIs have changed across versions.

Mitigation for TLD Operators

RFC 9276: Zero Iterations, Empty Salt

RFC 9276 specifies SHA-1, zero extra iterations, and an empty salt. Advice to use a long random salt, a high iteration count, and periodic salt rotation predates it and no longer holds.

• A salt provides no benefit here. Salts defend against tables precomputed in advance and reused across many targets. Zone walking is not that attack. An attacker walking a zone reads the salt from NSEC3PARAM and folds it into their hashing, leaving cost unchanged whether the salt is 16 random bytes or empty. Rotation forces a full resign for nothing.
• Iterations cost the operator more than the attacker. Every additional iteration is paid by every validating resolver on every negative answer, permanently. The attacker pays it once per candidate on hardware selected for the task. High iteration counts function as a self-inflicted denial-of-service vector, which is why RFC 9276 drove the recommendation to zero.

.com, .net, .eu, and .nl all publish 1 0 0 -.

NSEC3 parameters are not a lever for preventing enumeration. Where zone privacy is genuinely required, the leverage is in opt-out or in online signing.

Opt-Out

Opt-out is the setting with real effect on enumerable share, because it removes names from the chain rather than obscuring them.

This is a side effect rather than its purpose. Opt-out exists to keep the signed zone small when most delegations are unsigned, and its enumeration resistance diminishes as DNSSEC adoption rises. A registry at 60% signed gains little size benefit and little privacy benefit, which is broadly why .nl does not use it.

Online Signing with Minimally Covering NSEC

Registries and providers requiring genuine enumeration resistance use on-the-fly signing, described in RFC 4470 as "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 and returns a range just wide enough to cover the queried name. No chain links real name to real name, so there is nothing to follow.

The tradeoff is that the signing key must be online on the responding server rather than held offline in a signer, which suits managed providers more than offline registry signing operations.

NSEC5

NSEC5 proposed public-key cryptography in place of hashing for denial of existence, which would make enumeration infeasible regardless of dictionary size. It remains a research proposal and has not been adopted as an RFC.

What This Means for Registrants

Under a TLD using NSEC, or NSEC3 without opt-out, treat a domain registration as discoverable. This affects:

• Stealth product launches: registering a name before announcement may expose it
• Defensive registrations: typosquat-defensive portfolios can be enumerated
• Privacy: WHOIS privacy conceals registrant details, not the existence of the registration

Do not rely on registration obscurity for security or commercial secrecy. Where confidentiality matters until launch, use a different naming strategy, pick a TLD whose registry does not expose a walkable zone, or register through an intermediary.

Checking a TLD's Configuration

# Query a name that definitely does not exist under the TLD
dig +dnssec this-domain-does-not-exist-xyz123.se

# AUTHORITY section:
# - NSEC with readable names = walkable directly
# - NSEC3 with hashed names  = check the opt-out flag
# - No proof returned       = inconclusive; check the query, server, and validation chain

The second NSEC3 field contains flags for that record’s range. A value of 1 includes the opt-out bit and permits insecure delegations in that range to be omitted. One response does not establish the policy or coverage of every range in the zone. NSEC3PARAM flags are not this per-record opt-out indicator.

The DNS Inspector shows DNSSEC configuration for any domain or TLD.

Ethical and Legal Considerations

• The data is public by design: DNSSEC is built for anyone to verify, and NSEC/NSEC3 chains are part of the public DNS
• Large-scale enumeration may breach terms of service: many registry policies prohibit systematic collection
• Malicious use is illegal: collection may sit in a gray area, but using the results for phishing, spam, or unauthorized access does not
• Query volume is what gets noticed: a full walk means millions of queries against registry authoritative servers, and operators run detection for this pattern

Reporting a TLD's use of NSEC to its operator is not a security finding. Registries select their denial-of-existence scheme deliberately and with full awareness of the enumeration tradeoff. Pressure of that kind is also counterproductive, since a registry's available response includes closing off zone file access previously granted to researchers.

Perform TLD zone walking only for legitimate security research, with appropriate authorization, and in compliance with applicable law and policy.

This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Zone Walking for Subdomain Enumeration, DNS Zone Transfer Attack.