NSEC3 Next Secure v3 Common
Proves a name doesn't exist in a DNSSEC-signed zone using hashed names, preventing easy zone enumeration.
What it's for
NSEC3 does the same job as NSEC — proving a name doesn't exist in a DNSSEC-signed zone — but hashes each name before including it in the chain, instead of listing plaintext names. This directly addresses NSEC's main weakness: with plain NSEC, anyone can trivially "walk" the zone and enumerate every subdomain by following the next-name chain. NSEC3 makes that meaningfully harder, since an attacker only sees hashed values and has to reverse or brute-force them to recover actual names.
It's the more commonly deployed choice today for any zone where the list of existing subdomains is something you'd rather not hand out for free.
Format & syntax
a1b2c3d4e5f6.example.com. 3600 IN NSEC3 1 0 10 ABCD1234 G7H8I9J0K1L2 A MX RRSIG
- Hash Algorithm — which hash function was used (currently
1= SHA-1 is the only defined value) - Flags — mainly used for the "opt-out" bit, which allows insecure delegations to be skipped in the chain (useful for zones with a mix of signed and unsigned child zones)
- Iterations — how many times the hash is applied, adding computational cost to brute-force reversal attempts
- Salt — random data mixed into the hash to prevent precomputed rainbow-table-style attacks against the hashing
- Next Hashed Owner Name — the hash of the next name in the chain (in hashed order, not alphabetical)
- Type Bit Map — record types present at this name, same as NSEC
How it's used in practice
- Preventing zone enumeration while still supporting DNSSEC — the default choice for most managed DNSSEC implementations today, balancing authenticated denial of existence against not leaking your full subdomain list to anyone who asks.
- Opt-out delegations — large zones with many delegated but unsigned child zones (a common pattern at TLD-scale registries) use the opt-out flag to avoid needing an NSEC3 record for every single insecure delegation, which would otherwise bloat the zone significantly.
- Iteration count tuning — higher iteration counts increase the cost of reversing hashes but also increase CPU load on both the signer and validating resolvers; RFC 9276 recommends keeping iterations low (or zero) since higher counts provide diminishing security benefit while adding real computational cost.
Common mistakes & gotchas
- Assuming NSEC3 makes zone contents fully private — it raises the bar significantly but doesn't make enumeration impossible; short or predictable subdomain names can still be reversed via dictionary/brute-force attacks against the hash, especially with a weak salt or low iteration count. NSEC3 mitigates casual enumeration, it doesn't guarantee secrecy.
- Using unnecessarily high iteration counts — following outdated advice to maximize iterations actually just adds CPU cost for signers and resolvers without a proportional security benefit; current best practice (RFC 9276) recommends minimal iterations.
- Not understanding opt-out — for zones with many delegated child zones, incorrectly configuring (or not using) opt-out can bloat zone size unnecessarily, though this is mostly a registry-scale concern rather than something typical domain owners manage directly.
- Manually managing NSEC3 records — like NSEC, these are generated automatically by DNSSEC signing tooling, not hand-authored.
Comparison & FAQ
| Type | Purpose | Key difference from NSEC3 |
|---|---|---|
| NSEC | Same denial-of-existence purpose, plaintext names | Allows trivial zone walking; NSEC3 doesn't |
| NSEC3PARAM | Publishes the hashing parameters used for NSEC3 in the zone | A companion record, not an alternative — tells resolvers how to compute the hashes themselves |
Does NSEC3 completely prevent zone enumeration?
No — it makes casual enumeration significantly harder by hashing names, but determined attackers can still attempt to reverse hashes for short or guessable names, especially with weak salt or iteration settings. It's a meaningful mitigation, not an absolute guarantee.
Why would I choose NSEC3 over plain NSEC?
Almost every DNSSEC deployment today defaults to NSEC3 specifically because plain NSEC allows trivial full-zone enumeration by walking the next-name chain — NSEC3's hashing raises that bar substantially.
What does the "opt-out" flag do?
It lets a zone skip NSEC3 records for insecure (unsigned) delegated child zones, which matters most at large registries with many delegations, avoiding the overhead of covering every single insecure delegation in the denial-of-existence chain.
How many iterations should NSEC3 use?
Current best practice (RFC 9276) recommends low iteration counts, since higher values add real computational cost for signers and validators without a meaningful security improvement over a well-chosen salt and modern hash algorithm.