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

DNS zone walking is a technique that exploits DNSSEC's NSEC records to enumerate every name in a DNS zone. When applied to a TLD zone — like .com, .eu, or .org — this means an attacker can potentially discover every second-level domain registered under that TLD. Instead of finding subdomains within a single organization, TLD zone walking reveals the entire registry: every domain name that has been registered.

This is one of the most powerful reconnaissance techniques in DNS security. While zone walking for subdomain enumeration targets a single organization's zone, TLD zone walking targets the registry itself.

How TLD Zone Walking Works

TLD zones are DNS zones like any other — they contain records for every domain registered under that TLD. When a TLD zone is signed with DNSSEC using NSEC records, it creates a chain that links every registered domain name in alphabetical order.

The mechanics are the same as subdomain zone walking, but at a much larger scale:

1. Query for the TLD zone's first NSEC record
2. The response reveals the next registered domain name in the zone
3. Query for that domain's NSEC record
4. Repeat until the chain wraps back to the beginning

# Start walking the .example TLD zone
dig example NSEC +dnssec
# Returns: aardvark.example → NSEC → abbey.example

dig abbey.example NSEC +dnssec
# Returns: abbey.example → NSEC → ability.example

# Continue following the chain...

With automation, the entire registry can be enumerated. For smaller TLDs with tens of thousands of domains, this can complete in hours. For massive TLDs like .com with hundreds of millions of registrations, it would take much longer — but that is where NSEC3 hash cracking comes in.

No, You Cannot Parallelize the Walk

If you are staring at a TLD with millions of domains and thinking "I will just fire off thousands of concurrent queries to speed this up" — trust me, I had the same idea, and it does not work.

Zone walking is inherently sequential. Each NSEC response tells you the next name in the chain, and you cannot query for the next name until you know what it is. You need the response from query N to construct query N+1. There is no way to skip ahead or split the work across threads because you simply do not know what names exist until the chain tells you.

Query: dig aardvark.example NSEC → Response: abbey.example
Query: dig abbey.example NSEC    → Response: ability.example
Query: dig ability.example NSEC  → Response: ???
# You literally cannot send this query until you get the previous answer

You cannot guess the gaps. You cannot start from the middle. You cannot divide the alphabet into ranges and walk each range in parallel. The whole point of NSEC is that it chains existing names — and the existing names are not evenly distributed or predictable.

The one thing you can parallelize is the NSEC3 hash cracking step. Once you have collected all the hashes (which is still a sequential walk), cracking them against a dictionary is embarrassingly parallel and scales beautifully across GPUs. So the slow part is the walk itself — the fast part is the cracking afterward.

Why TLD Zone Walking Matters

The stakes are higher when walking a TLD zone compared to walking a single domain's subdomains:

• Complete registry enumeration — every registered domain under the TLD is exposed, not just subdomains of one domain
• Brand and trademark intelligence — discover unreleased product names, defensive registrations, and brand-related domains
• Competitive intelligence at scale — see what domains competitors have registered before they launch
• Phishing and typosquatting analysis — identify all domains similar to a target for takedown or monitoring
• Market research — understand registration trends, popular keywords, and naming patterns within a TLD
• Attack surface mapping — combine with DNS lookups to map the infrastructure behind discovered domains

Researchers have used TLD zone walking to build complete databases of domain registrations, sometimes publishing them publicly. This data has legitimate uses in security research but also enables abuse.

Which TLDs Are Vulnerable?

Not all TLDs are equally exposed. The key factor is whether the TLD zone uses NSEC or NSEC3:

TLDs Using NSEC (Trivially Walkable)

Some smaller or older TLDs still sign their zones with plain NSEC records. These are completely walkable — every registered domain is exposed in cleartext through the NSEC chain. An attacker with ldns-walk or a simple script can enumerate the entire zone.

# Check if a TLD uses NSEC
dig nonexistent-test-domain.eu NSEC +dnssec

# If the authority section shows NSEC records with readable
# domain names, the zone is trivially walkable

TLDs Using NSEC3 (Harder but Not Impossible)

Most major TLDs — including .com, .net, .org, and many ccTLDs — use NSEC3. This was widely adopted specifically to prevent trivial zone walking. But here is the critical point that is often misunderstood:

NSEC3 makes zone walking significantly harder but not impossible. The hashes can be cracked with enough computational effort and a good dictionary.

Why NSEC3 Does Not Fully Prevent TLD Zone Walking

NSEC3 replaces cleartext domain names with hashed versions in the NSEC chain:

# Instead of: aardvark.example → abbey.example → ability.example
# NSEC3 shows: 1a2b3c4d → 5e6f7a8b → 9c0d1e2f

On the surface, this looks like it solves the problem. But the hash algorithm (SHA-1), the salt, and the iteration count are all public — they are stored in the NSEC3PARAM record for the zone, which anyone can query:

dig eu NSEC3PARAM +short
# Returns: 1 0 10 a1b2c3d4
# Algorithm=1(SHA-1), Flags=0, Iterations=10, Salt=a1b2c3d4

With these parameters in hand, an attacker can:

1. Collect all NSEC3 hashes by walking the hashed chain (this still works — the chain structure is intact, only the names are hashed)
2. Build a dictionary of candidate domain names — common words, brand names, dictionary words, previously known domains
3. Hash each candidate using the same algorithm, salt, and iterations
4. Compare against the collected hashes — any match reveals a registered domain

The Scale of the Problem

This is not theoretical. Tools like nsec3map, nsec3walker, and hashcat automate this entire process:

• nsec3map walks the NSEC3 chain, collects all hashes, then cracks them against a wordlist
• hashcat can use GPU acceleration to test billions of candidates per second
• A standard English dictionary combined with common domain patterns can crack a significant percentage of domain names in any TLD

For TLD zones, the dictionary attack is particularly effective because:

• Most domain names are dictionary words or simple combinations (shop, blue, tech, mysite)
• Brand names and company names are well-known and easily added to wordlists
• Previous zone walk results can seed future dictionaries
• Short domain names (1-6 characters) can be brute-forced exhaustively

Research has shown that 50-80% of domain names in a typical TLD zone can be recovered from NSEC3 hashes using dictionary attacks with moderate computational resources.

Tools for TLD Zone Walking

Several tools exist for walking TLD zones, each with different capabilities:

For NSEC Zones

# ldns-walk — simple and effective for NSEC zones
ldns-walk eu

# nsec-walker — another option
nsec-walker eu

For NSEC3 Zones

# nsec3map — walks NSEC3 chain and cracks hashes
nsec3map eu -o eu_hashes.db

# Then crack the collected hashes against a dictionary
nsec3map crack eu_hashes.db -w wordlist.txt

# hashcat — GPU-accelerated NSEC3 hash cracking
# Mode 8300 is for NSEC3 hashes
hashcat -m 8300 hashes.txt wordlist.txt

Real-World TLD Zone Walking

Several notable TLD zone walking efforts have been documented:

• Researchers have enumerated entire ccTLD zones and published the results, revealing the complete set of registered domains
• The .com zone is available through zone data access programs for approved applicants — but zone walking provides an alternative path without requiring approval
• Security researchers regularly walk smaller TLD zones to study registration patterns, identify malicious domains, and track brand abuse
• Some TLD operators have switched from NSEC to NSEC3 specifically after zone walking incidents exposed their registries

How TLD Operators Can Mitigate This

Use NSEC3 with Strong Parameters

At minimum, TLD operators should use NSEC3 instead of NSEC. While NSEC3 is not a complete solution, it raises the cost of enumeration significantly:

• Use a random salt of sufficient length
• Use an appropriate iteration count — though RFC 9276 now recommends lower iterations (0-10) due to the computational burden on resolvers, acknowledging that high iteration counts do not meaningfully improve security against offline cracking
• Rotate the salt periodically to invalidate previously collected hash databases

NSEC5 (Proposed)

NSEC5 is a proposed extension that would use public-key cryptography instead of hash functions for denial of existence. This would make zone walking computationally infeasible regardless of dictionary size. However, as of this writing, NSEC5 remains a research proposal and has not been adopted as an RFC.

Minimize Zone Information

Some TLD operators use techniques to reduce the information available through zone walking:

• Opt-out — NSEC3 opt-out allows unsigned delegations to be excluded from the NSEC3 chain, reducing the number of entries an attacker can collect
• Empty non-terminals — careful zone construction can reduce the useful information in NSEC3 chains

What This Means for Domain Registrants

If you register a domain under a TLD that uses NSEC (or NSEC3 with weak parameters), you should assume that your domain registration is discoverable. This has implications for:

• Stealth product launches — registering newproductname.com before announcement may be discoverable through zone walking
• Defensive registrations — typosquat-defensive registrations can be enumerated
• Privacy — even with WHOIS privacy, the existence of a domain registration is exposed through DNSSEC

The practical takeaway: do not rely on domain registration obscurity for security or business secrecy. If you need to keep a domain name confidential until launch, consider using a different naming strategy or registering through intermediaries.

How to Check a TLD's DNSSEC Configuration

You can check whether a TLD uses NSEC or NSEC3 with a simple query:

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

# Look at the AUTHORITY section:
# - NSEC records with readable names = trivially walkable
# - NSEC3 records with hashed names = harder but crackable
# - No DNSSEC records = zone is not signed (not walkable via NSEC)

You can also use the DNS Inspector to examine DNSSEC configuration for any domain or TLD.

Ethical and Legal Considerations

Zone walking TLD zones raises significant legal and ethical questions:

• The data is technically public — DNSSEC is designed so that anyone can verify its records, and NSEC/NSEC3 chains are part of the public DNS
• Large-scale enumeration may violate terms of service — many TLD operators prohibit systematic data collection in their policies
• Using the data for malicious purposes is illegal — while collecting the data may be in a gray area, using it for phishing, spam, or unauthorized access is clearly prohibited
• Responsible disclosure — if you discover a TLD using NSEC instead of NSEC3, consider notifying the TLD operator

Only perform TLD zone walking for legitimate security research, with appropriate authorization, and in compliance with applicable laws and policies.

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.