A DNSSEC signature can authenticate data that exists, but a resolver also needs cryptographic evidence when a requested name or record type is absent. A plain unsigned NXDOMAIN response cannot provide that property: an attacker able to alter DNS traffic could fabricate the same response. NSEC3 supplies signed denial records while replacing clear-text owner names in the denial chain with hashes.
RFC 5155 defines NSEC3 as an alternative to NSEC for authenticated denial of existence. Its main privacy-related distinction is narrow but useful: walking an NSEC chain directly reveals neighboring owner names, whereas NSEC3 exposes hashes that require additional work to map back to candidate names.
NSEC3 is not a confidentiality mechanism for DNS names. Guessable labels can still be tested offline against an observed chain, and current operational guidance treats extra hash work as a poor trade when it raises authoritative-server and resolver cost.
Negative answers still need signed evidence
DNSSEC validation is based on signed RRsets and a chain of trust. For a positive answer, the resolver can validate the returned RRset and its RRSIG. A negative answer needs a different statement: the zone has to prove that the queried name does not exist, or that the name exists but the requested record type does not.
NSEC3 represents ordered intervals in a hashed namespace. Each NSEC3 record identifies its own hashed owner name, the next hashed owner name in the chain, protocol parameters, and a bitmap of record types present at the original owner name.
A simplified view is:
original owner names
|
v
NSEC3 hash
|
v
H1 --------> H2 --------> H3
| | |
+-- signed ---+-- signed ---+For a missing name, a validating resolver checks the relevant signed NSEC3 records and verifies that the hashed query falls into the interval required by the denial proof. DNSSEC signatures authenticate those NSEC3 RRsets; hashing alone does not.
Hashing changes enumeration, not the existence proof
With NSEC, a denial record names the next existing owner directly. Repeated queries can therefore expose the ordered set of names in a zone. NSEC3 moves that ordering into hash space.
RFC 5155 currently defines NSEC3 hash algorithm 1 as SHA-1 for this construction. The input incorporates the fully qualified domain name and the configured salt, then applies the configured number of additional iterations. The resulting hash is encoded into the NSEC3 owner label.
That design blocks direct reading of the next original owner name from the chain. It does not make low-entropy names secret. An observer can collect NSEC3 hashes, generate candidate names such as common service labels, apply the zone’s published NSEC3 parameters, and compare the results offline.
The distinction matters operationally. NSEC3 raises the cost of straightforward zone enumeration, but it does not provide a strong secrecy boundary for predictable DNS labels.
Zero iterations still performs one hash
The NSEC3 Iterations field counts additional hash applications after the first one. An iteration value of 0 therefore means one hash computation, not zero hashing.
Earlier deployments sometimes used extra iterations to increase the cost of dictionary attacks. RFC 9276 updates that operational guidance. It requires an iteration count of 0 when NSEC3 is used, because extra iterations add computation for publishers and validators while offering diminishing resistance against offline guessing.
The recommended NSEC3 parameters in RFC 9276 are represented as:
bcp.example. IN NSEC3PARAM 1 0 0 -The fields select SHA-1, no flags in NSEC3PARAM, zero additional iterations, and an empty salt.
This recommendation is partly a denial-of-service concern. A validator processing negative answers must perform the NSEC3 hashing needed for validation. Raising the iteration count raises that work for legitimate validators as well as for an attacker testing candidate names.
Salt does not create durable secrecy
NSEC3 can include a salt in its hash input. In a conventional password-hashing setting, salts prevent one precomputed table from being reused broadly. DNS zones already include the full domain name in the hash input, so candidate computations are naturally specific to a zone.
RFC 9276 recommends an empty NSEC3 salt. A static extra salt does not stop an observer from computing a candidate dictionary for the zone after obtaining the salt, because the salt is published as part of the NSEC3 parameters. Rotating salts frequently would require rebuilding the NSEC3 chain and re-signing the zone, adding operational cost.
An empty salt is written as - in presentation format. Removing the salt does not remove DNSSEC authentication. The security property of the denial proof comes from signatures and the DNSSEC chain of trust, not from secrecy of the NSEC3 hash input.
Opt-Out changes the statement around unsigned delegations
NSEC3 includes an Opt-Out flag designed for zones with many unsigned delegations. When Opt-Out is set on an NSEC3 record, its interval may cover one or more unsigned delegations that do not have their own NSEC3 owner entry.
This can reduce the number of NSEC3 records needed in very large, sparsely signed delegation-centric zones. It also changes what the denial chain proves across those intervals. RFC 9276 does not recommend Opt-Out for small zones; it permits the mechanism for very large zones where most relevant entries are insecure delegations.
Opt-Out must not be treated as a generic performance switch. Its semantics are tied to unsigned delegations, and validators apply special proof rules around closest enclosers, next-closer names, and wildcard denial.
NSEC3PARAM is publication metadata, not the validation proof
The zone apex can publish NSEC3PARAM to describe parameters used for generating an NSEC3 chain. Its fields mirror the hash algorithm, flags, iterations, and salt used by NSEC3.
Validating resolvers do not use NSEC3PARAM as the authoritative source for validating an individual denial proof. The NSEC3 records themselves carry the parameters needed for that processing and are protected by their RRSIG records.
This separation matters during parameter changes. A publisher can construct a replacement NSEC3 chain and re-sign the zone as part of a controlled transition. Merely editing NSEC3PARAM does not transform an existing chain.
NSEC remains the simpler default when NSEC3 features are unnecessary
RFC 9276 recommends NSEC in preference to NSEC3 when the operational or security features of NSEC3 are not required. NSEC avoids NSEC3’s hash computation and its more complex denial processing, at the cost of exposing owner-name ordering directly.
That leaves a concrete deployment choice rather than a universal hierarchy. NSEC offers simpler authenticated denial with easy zone walking. NSEC3 obscures the owner names in the denial chain and supports Opt-Out, but adds hashing, proof complexity, and only moderate resistance to enumeration of predictable names.
The cryptographic boundary stays the same in both cases: denial is trustworthy because signed DNSSEC data proves it. NSEC3 changes the representation of that proof and the information exposed by the chain; it does not turn public DNS naming into confidential data.