NSEC and NSEC3 Records in DNSSEC: How They Prevent Zone Walking and Authenticate Denial of Existence

What Problem Do NSEC and NSEC3 Solve?

DNSSEC (Domain Name System Security Extensions) ensures that DNS responses are authenticated with digital signatures. If a resolver requests a record that does exist, the server signs the answer. But what happens when a resolver asks for a name that doesn’t exist? A normal DNS server replies with NXDOMAIN, but an attacker could forge that reply and send you anywhere. DNSSEC needs a way to cryptographically prove that a name is genuinely absent from a zone. That’s exactly what NSEC and NSEC3 records were designed to do.

NSEC: Authenticated Denial, But at a Cost

An NSEC (Next Secure) record lists the next canonical name in the zone. Every name in a signed zone has an NSEC record that points to its alphabetic successor. Together, these records form a complete chain around the zone. When a resolver asks for a nonexistent name, the server returns an NSEC record that demonstrates “no existing name falls between this predecessor and this successor.” That signed proof is cryptographically valid, so the resolver can trust the denial.

The problem? NSEC leaks the entire zone contents. Because each NSEC record contains the plaintext next name, an attacker can start at the first record and follow the chain, listing every regular name and subdomain in your zone. This is called zone walking, and it’s a serious privacy and security issue. Zone walking can expose hidden services, internal staging environments, or simply give attackers a complete map of your attack surface. For a blog or a small business, it may not be catastrophic, but for registries and large organizations, it can be unacceptable.

NSEC3: Hashing the Chain to Stop Walkers

NSEC3 solves the zone walking problem by hashing the owner names before linking them. Instead of exposing the next plaintext name, an NSEC3 record contains the hash of the next name. The chain consists of hashed names arranged in hash order, not alphabetical order. To prove a name doesn’t exist, the server returns the NSEC3 record whose hash range covers the hashed query name. Because hashes are one-way, an attacker cannot directly recover the original names from the NSEC3 records. They’d have to try candidate names, hash them, and match — at best a slow dictionary attack, not an instant walk.

NSEC3 also lets zone administrators add two important parameters:

• Salt: A random value prepended to each name before hashing. Salt makes precomputed rainbow tables useless, forcing attackers to brute-force per-zone.
• Iterations: The number of times the hash is applied. Higher iterations slow down brute-force attempts, but also consume more CPU power on the authoritative server for every denial response.

Many registries and operators still use NSEC3, although the root zone famously still uses plain NSEC because of performance and legacy resolvers. Still, if you control a zone, NSEC3 is the safer default.

NSEC3 Opt-Out: A Trade-Off for Large Zones

In enormous zones like .com or .net, many delegations belong to names that aren’t signed with DNSSEC. Without a special mechanism, NSEC3 would require the registry to add hash-chain records for every unsigned delegation, bloating the zone and increasing signing/querying overhead. NSEC3 opt-out allows the registry to skip hashing unsigned delegations entirely. When a nonexistent name falls into an “opt-out” gap, the server returns an NSEC3 record that proves the absence but with slightly weaker authenticity proof. This is fine for normal resolvers and saves significant resources, but it means that unsigned delegations adjacent to the gap are not individually verified. If you’re a security purist, you’ll want to know whether your provider uses opt-out, but in practice it’s a reasonable compromise for huge registries.

Real-World Example: Why the Difference Matters

Imagine an attacker wants to enumerate every subdomain under example.com. With an NSEC-signed zone, they request a.example.com, which doesn’t exist. The response includes an NSEC record saying the next existing name is api.example.com. Then they request api.example.com, get the next name admin.example.com, and so on. Within minutes they have a complete list of your internal and external subdomains.

With NSEC3, the response contains a hashed name like 3h9v02...example.com. The attacker can’t reverse it, so they’re forced to guess names. If your subdomains are random and your salt is long, that’s effectively impossible. However, if you use common names like www, dev, or staging, a dictionary attack against a weak salt could still recover them. This is why NSEC3 doesn’t make zone walking impossible — it just makes it expensive and significantly harder for random or obscure names.

Actionable Advice for Zone Operators

• Choose NSEC3 for new zones. If your DNS software supports it (BIND, PowerDNS, Knot, and most managed providers do), enable NSEC3. It’s a low-cost privacy win. Only stick with NSEC if you’re serving ultra-high-performance zones where every millisecond and byte matters, or if you must support ancient resolvers.
• Use a long random salt and a sane iteration count. A salt of at least 64 bits (8 bytes) is a good starting point. Iterations between 100 and 1000 are practical; don’t crank it to 100,000 unless you’re willing to eat the CPU cost on every query.
• Audit your configuration. You can use the DNS Analyzer on Whose.Domains to inspect the records in your zone, including whether your denial-of-existence responses use NSEC or NSEC3. Look for the RRSIG over the NSEC/NSEC3 records and confirm your chain is complete.
• Don’t rely on NSEC3 to hide secrets. Even with NSEC3, a determined attacker with a strong wordlist may eventually guess your names. If you have truly sensitive subdomains, keep them out of public DNS entirely, or give them random hostnames with a long salt.

Final Thoughts

NSEC and NSEC3 are both essential parts of DNSSEC, but NSEC3 is the more privacy-preserving choice. It authenticates denial of existence without handing out a roadmap to your zone. Whether you’re managing a single domain or an entire registry, understanding these records helps you make smarter security decisions. And when you’re debugging a DNSSEC issue or simply verifying your setup, a good DNS Analyzer can show you exactly what your server is sending — and what it’s protecting.