Blog: Show on homepage

DNSSEC NSEC. The accidental treasure map to your subdomains

Darrell Hall 04 Mar 2025

TL;DR:

DNSSEC secures DNS but may unintentionally expose domain structures via NSEC/NSEC3 records, enabling zone walking to enumerate subdomains.
NSEC openly lists domain names, making enumeration easy.
NSEC3 hashes names, making enumeration harder, but attackers can still crack weak configurations.
Zone Walking allows attackers to extract valid domains even when zone transfers (AXFR) are blocked.

Introduction

The Domain Name System (DNS) plays a critical role in mapping human-readable domain names to IP addresses. However, like any decentralised system, it has its vulnerabilities. DNS Security Extensions (DNSSEC) were introduced to enhance DNS security, but they inadvertently introduced a technique known as zone walking, which allows attackers or researchers to enumerate DNS records in a domain.

This post dives into how zone walking works, how it differs from zone transfers, and how to mitigate the risks. We will also cover methods for cracking NSEC3 records and highlight how some DNS providers are now mitigating these risks with on-the-fly cryptographic signing.

What is DNS?

First, let’s talk about what DNS is. The Domain Name System (DNS) is like the internet’s phonebook, converting human-friendly domain names (e.g., `example.com`) into machine-readable IP addresses. This allows computers to find and communicate with each other seamlessly. DNS operates through a hierarchical system of name servers, ensuring fast and efficient query resolution.

So, what is DNSSEC?

DNSSEC was designed to add cryptographic signatures to DNS records, ensuring data integrity and authenticity. It prevents attackers from tampering with DNS responses or launching cache poisoning attacks.

However, DNSSEC also unintentionally exposes some information that can be leveraged to enumerate all domain names in a zone, a process known as zone walking.

What is DNSSEC Zone Walking?

Zone walking is a technique used to list all subdomains within a DNSSEC-protected zone. It occurs due to the way DNSSEC handles non-existent domain names.

When a query is made for a non-existent domain, DNSSEC must provide proof that the name does not exist. This proof is provided using Next Secure (NSEC) or NSEC3 records. These records create a way to methodically discover valid domain names in the zone.

What are NSEC records?

NSEC was the first mechanism introduced by DNSSEC to prove the non-existence of a domain name. It works by linking records in a sorted list, explicitly stating that no records exist between a given domain and the next one in the sequence.

While this method allows resolvers to verify the absence of a domain, it also exposes the structure of the DNS zone. By repeatedly querying for non-existent domains and analysing the resulting NSEC responses, attackers can systematically enumerate all valid domain names within the zone.

What is NSEC3?

NSEC3 was introduced as an improvement over NSEC to prevent zone enumeration while still proving the non-existence of a domain name in DNSSEC. Instead of listing domain names in plain text, NSEC3 uses cryptographic hashing to obscure them, making it more difficult for attackers to map out an entire DNS zone.

While this method reduces the risk of direct enumeration, it is not entirely foolproof. Attackers can still perform offline dictionary attacks to reverse-hash common domain names, especially if weak hashing parameters are used. Nonetheless, NSEC3 provides stronger protection against large-scale zone enumeration compared to its predecessor.

Zone Transfers vs. Zone Walking

A zone transfer is when a DNS server sends a full copy of its DNS records to another server, typically for redundancy or failover. It is usually performed using AXFR (Authoritative Transfer) requests.

If an attacker can request a zone transfer (often due to misconfiguration), they can obtain every domain and subdomain in one go.

How is Zone Walking Different?

Zone transfers give immediate, full access to DNS records (if misconfigured).
Zone walking is slower and requires enumerating records one by one, but works even if AXFR is disabled.

While most DNS providers now block unauthorised AXFR requests, zone walking remains a risk if DNSSEC is improperly configured.

Example of Zone Walking with NSEC

An attacker can use dig to enumerate DNSSEC-enabled zones that implement NSEC by repeatedly querying for non-existent subdomains and analysing the responses.

Before you start, pick a domain / TLD that you suspect uses NSEC rather than NSEC3. For example, the Top Level Domain (TLD) (.cars).

Check if the NSEC is enabled :

Dig response with NSEC response with first record:

This indicates that no valid domains exist between 0.cars and 8va.cars as the first available next domain response was 8va.cars.

To discover the next domain, the attacker modifies the queried domain name by changing the last character or systematically guessing names to iteratively uncover valid domains. For example, after identifying 8va.cars, the next logical step is to query 8vb.cars to retrieve the next NSEC record.

Check the next record:

The response reveals:

This indicates that 8xbet.cars is the next valid domain in the sequence. By querying for the next NSEC record using 8xbet.cars, an attacker can progressively uncover additional domain names. By systematically querying non-existent domains and analysing NSEC responses, the attacker can gradually enumerate all valid domain names within the zone.

Example of Zone Walking with NSEC3

Below demonstrates how to replicate the NSEC3 enumeration process. Although the below focuses on enumerating domains at the TLD level, these steps also work for subdomains in an NSEC3-enabled zone. Simply adapt the domain and subdomain details accordingly.

Confirm the Zone uses NSEC3

Like the NSEC example choose a domain that you suspect uses NSEC3 rather than NSEC. For example, some TLDs like (.sh) often have NSEC3 enabled.

Check DNSSEC

Look in the response to confirm you see DNSSEC data. If you also suspect NSEC3, you’ll often see references to NSEC3 in negative or authority answers.

Find the authoritative nameservers

Every domain has at least one authoritative nameserver. We want to send queries straight to the authoritative server to ensure we get the full DNSSEC negative responses.

List the Domain’s NS Records:

That should return something like:

Resolve Their IPs :

Now you have the direct IP for the authoritative nameserver.

Generate a random subdomain

The idea is that we’ll query a non-existent subdomain (like blabla-rand-abc.example.tld) in order to trigger an NSEC3 negative response.

Python can be used to generate a random UUID:

That outputs something like:

Append your domain:

Query the Random Subdomain with DNSSEC:

The authoritative server should respond with something like NXDOMAIN or SERVFAIL (depending on the zone’s policy), and in the Authority section you should see lines like:

Each NSEC3 record defines a range of hashed domain names, specifying which names do not exist within that range. The response will include an NSEC3 record containing a hashed domain, such as ibrth72s0grqj0ig2j27bghskakrhr6u, which represents a hashed label in the zone’s denial of existence chain. By analysing these records, an attacker can map the hashed namespace and attempt to reverse the hashes to uncover valid domain names.

Extracting the collected hashes

Looking at the AUTHORITY SECTION, we identify three NSEC3 records, each revealing a (hash, next-hash) pair.

From the response, we collected these three NSEC3 records:

Each NSEC3 record contains two hashed domain names, so in total:

3 NSEC3 records × 2 hashes per record = 6 hashes collected.

Cracking the hashes

Extract the Salt & Iteration Count from the previous dig command:

In this case:

Algorithm: 1 (SHA-1)
Iterations: 0
Salt: 73

Save your hashes in a file (nsec3-zones.hashes):

Brute-force the hashes using Hashcat:

If successful it will reveal the real domain names!

To achieve broader NSEC3 coverage, repeat the process by generating another random subdomain and querying it using DNSSEC. Each query will return new NSEC3 records, revealing additional hashed ranges in the zone. By parsing these “next” ranges from the responses, you gradually map out the hashed namespace. After conducting enough iterations, you will have collected most of the possible hashed segments, allowing you to perform a comprehensive NSEC3 walk of the zone and uncover hidden domain structures

Final thoughts and conclusion

Addressing NSEC zone walking involves balancing the practical needs of your organisation with the resources available. If domain enumeration is not a major concern, you may find that the simplicity and lower overhead of traditional NSEC is perfectly adequate.

However, for domains requiring tighter privacy controls, such as top-level domains or organisations hosting sensitive subdomains, NSEC3 with robust, properly salted, and iterated hashing parameters is a more prudent choice. Configured correctly, this approach makes brute-force attempts more difficult and helps preserve the confidentiality of internal domain structures.

For those seeking the next level of privacy, ‘DNSSEC White Lies’ (RFC 4470 and RFC 4471) is worth exploring. This technique can frustrate attempts at zone enumeration by serving an artificial NSEC3 record, preventing attackers from simply walking the zone to learn its structure. That said, it does require real-time signature generation on the authoritative server, which may not be feasible for all environments.

As discussed in our previous blog post about DNS, it’s important to recognise that DNS was never designed with privacy in mind. This raises the question: should we prioritise good operational security (OpSec) over security through obscurity, or should we use a combination of both?

In reality, the best approach is often a balance between strong OpSec and limited obscurity. Hiding sensitive assets can be useful, but it should never be your primary security strategy. Instead, organisations should focus on reducing their attack surface and securing critical infrastructure

Ultimately, the decision to deploy NSEC, NSEC3, or White Lies depends on your risk appetite, the sensitivity of your domains, and the operational overhead you can handle. Some organisations value the transparency that comes from using NSEC, whereas others prioritise privacy above all else. By thoughtfully weighing these considerations, you can tailor a DNSSEC solution that meets both your security requirements and operational capabilities.

DNSSEC is a vital component of modern internet security, but like any security measure, it requires careful implementation. The goal is not just to deploy DNSSEC, but to configure it in a way that minimises unintended exposure while maintaining the integrity of your domain. A well-planned approach ensures that your DNS remains both secure and resilient against emerging threats.