DNS Zone Walking at the TLD Level: How Attackers Discover Every Domain in a TLD

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.

How much of a registry a walk actually yields is decided by one setting: the NSEC3 opt-out flag. Not by hash cracking, not by wordlist quality, and not by how much GPU time is available. Because most large TLDs enable opt-out, only DNSSEC-signed delegations enter the chain at all. Measuring the zone files directly in July 2026, DNS Checker finds 4.5% of .com domains are DNSSEC-signed (7,762,604 of 172,738,866), which is the practical ceiling on what a .com walk can reach. The registries that are genuinely enumerable are those using plain NSEC, such as .se, or NSEC3 without opt-out, such as .nl.

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 registered domains.

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

One query about a domain that was never registered returns two that were.

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 registered domain 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.

The Opt-Out Ceiling

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)

For an opt-out TLD, the number of names in the chain tracks that TLD's DNSSEC adoption rate closely. The chain also carries the apex and some empty non-terminals, so the figures below are close approximations rather than exact protocol-derived limits.

Measured from DNS Checker's own zone data, July 2026:

Walk .com flawlessly, crack every hash collected with an unlimited wordlist, and the result is roughly 5% of the zone. The remainder never enabled DNSSEC and so was never chained.

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, in GPU-Based NSEC3 Hash Breaking (IEEE NCA 2014), recovered 64% of the DNSSEC-signed names in .com in 4.5 days of GPU time. That 64% is a crack rate against the names present in the chain, which under opt-out is the signed minority. Applied to the measured signing rate, 64% of 4.5% is approximately 2.9% of the .com zone.

The measurement is sound. The denominator is what gets substituted. Two distinct quantities are involved:

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 the second dominates by more than an order of magnitude.

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, the registered domain list is derivable from DNS alone
• 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 DNSSEC records        = zone unsigned, not walkable this way

For NSEC3 responses, read the second field of the record. 1 1 0 means opt-out is enabled and only signed delegations are chained. 1 0 0 means opt-out is disabled and the whole zone is represented.

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.