Summary

  • An NSEC3 Opt-Out interval may cover a real insecure delegation while asserting neither that the delegation exists nor that it does not. A signed chain reconstructed from its nodes is therefore a denial projection, not an authenticated copy of the parent zone's complete delegation inventory.
  • The parent operator must keep the source inventory, signer output and live NS/DS behavior as separate evidence layers. Any audit, security product or resolver optimization that turns an Opt-Out span into a verdict of absence has exceeded the proof it received.

Imagine a deliberately illustrative reconciliation exercise. An auditor walks every node in a correctly signed NSEC3 chain and finds no node corresponding to retail.example. Its report marks the child as absent. A direct query to the same parent zone returns a normal referral: the child has NS records but no DS records. The delegation exists and is insecure.

Nothing cryptographic has failed. The auditor has asked the chain to answer a question it was designed not to answer.

RFC 5155 permits a parent using NSEC3 Opt-Out to exclude the hashed owner names of eligible insecure delegations. The NSEC3 record spanning the omitted hash carries the Opt-Out flag. That record makes a precise claim about the signed denial structure, but expressly makes no claim about whether an insecure delegation inside its span exists. The parent can add or remove such a delegation without recalculating the adjacent chain nodes.

The efficiency is valuable in a very large, delegation-heavy zone. The proof gap is equally real. A consumer that equates “not represented by a node” with “not present in the zone” has silently converted a bounded protocol statement into an inventory mandate.

Two ledgers, two jobs

The source zone and the NSEC3 chain are related, but they are not interchangeable ledgers.

The source inventory answers operational questions: which child name is delegated, which NS RRset belongs at that cut, whether glue is present, whether the child has a DS RRset, when the record changed and which provisioning decision authorized it. The signer consumes that state and constructs a denial chain under a selected algorithm, flag, iteration and salt policy.

NSEC3 places hashes of represented owner names in hash order. Each record identifies the next hash and carries a bitmap of RR types present at its original name. A validator can use matching and covering records, with valid RRSIGs, to test a particular denial. It does not receive a reversible export of every original name.

Opt-Out narrows the projection further. An insecure delegation is a delegation NS RRset without a DS RRset. Its hashed owner name may be omitted if an Opt-Out NSEC3 interval covers the relevant hash. A secure delegation cannot be made eligible by convenience: DS is authoritative parent-zone data, and the chain construction still has to represent the names and RRsets that the protocol requires. Nor may an operator omit arbitrary authoritative names, ordinary data or a secure child and call the gap an optimization.

The evidence record should therefore preserve five distinct objects:

  1. the source delegation entry;
  2. its security status, determined by the parent-side DS state;
  3. the signer input and signing-generation identifier;
  4. the exact NSEC3 matching or covering record, including its flag and hash interval; and
  5. what every material authoritative server actually returns for NS, DS and denial queries.

When those objects are collapsed into one “DNSSEC valid” field, the most important distinction disappears.

A non-assertion is not a negative answer

The word “denial” invites an overbroad reading. In an Opt-Out span, the signed record is not saying that every possible child name in the interval is nonexistent. It is saying that the interval may contain omitted insecure delegations while still serving the protocol's denial requirements for other authoritative data.

That distinction changes how evidence must be consumed. A direct referral can demonstrate that an insecure delegation is live even though the chain contains no matching node for its name. An authorized zone transfer or registry export can supply a complete inventory. The NSEC3 chain alone cannot.

It also changes resolver behavior. RFC 8198 allows a validating resolver to reuse some validated NSEC or NSEC3 ranges to synthesize negative answers without querying the authority again. That optimization stops at this boundary: if the covering NSEC3 record has Opt-Out, it does not prove the queried name's non-existence, so aggressive negative synthesis is not permitted for that name.

An inventory scanner should apply the same discipline even though it is not a resolver. For every Opt-Out interval, its result is not ABSENT; it is INDETERMINATE_FROM_CHAIN. The scanner may then consult an authorized source inventory or issue direct queries. The extra step is not a workaround. It is the only way to ask the missing question of a surface that has authority to answer it.

Closest is not always closest provable

NSEC3 denial processing also separates the closest encloser from the closest provable encloser. The closest encloser is the longest existing ancestor of a queried name. In an Opt-Out zone, an insecure delegation or an empty non-terminal derived only from it may lack its own NSEC3 node. The proof may therefore stop at the longest ancestor whose existence the chain can actually demonstrate.

This is not semantic decoration. Wildcard and name-error validation depend on knowing which ancestor exists, which next-closer name is covered and whether a wildcard could have supplied the answer. A consumer that discards the Opt-Out flag or keeps only a normalized “negative” outcome loses the reason the proof terminated where it did.

Keep the raw response, RRSIG, NSEC3 fields, queried name, closest-encloser calculation and validator result. Preserve whether the covering record matches or spans the relevant hash and whether the interval wraps around the end of hash space. A screenshot of a green validator light cannot reconstruct that decision later.

The modern parameter baseline is intentionally plain

NSEC3 was introduced partly to make straightforward zone enumeration harder. It also added computational work and operational complexity. Current best practice in RFC 9276 is more restrained than many older deployment habits.

If NSEC3's features are not needed, use NSEC. If NSEC3 is needed, use hash algorithm 1, zero extra iterations and an empty salt. Extra iterations multiply work for authoritative systems and validating resolvers while offering poor practical protection against guessing. A salt changes hashes, but it does not turn predictable names into secrets. The current guidance therefore does not treat rotating salt or raising the iteration count as a security maturity signal.

The Opt-Out decision is narrower still. It is not recommended for small zones. It may be justified in very large, sparsely signed, delegation-centric zones where most records are insecure delegations and rebuilding the chain for every delegation change carries material cost. The operator should document that scale and mix rather than inherit Opt-Out from an old signer profile.

Resolver policy is another separate layer. A validator may reject, return SERVFAIL or treat a response as insecure when the NSEC3 iteration count exceeds its supported limit. After the relevant record has been validated, it may report Extended DNS Error 27 for unsupported NSEC3 iterations. That outcome describes a validation-resource policy. It does not prove that a child delegation is absent, and it does not repair an incomplete inventory.

Parameter change is a generation change

The NSEC3PARAM record at the apex advertises parameters useful to authoritative generation, but validators validate the parameters carried in the NSEC3 records before them. Changing salt or iterations requires a complete new chain and a re-signed zone. It is not a local metadata edit.

A safe change dossier identifies the source-zone serial or generation, old and new NSEC3 parameter sets, all nodes in each chain, signature windows, transfer completion at every secondary and the moment each serving instance activates. Known non-existent labels test negative behavior; known insecure and secure delegations test the Opt-Out boundary; wildcard names test closest-encloser handling.

During rollout, “one server answered correctly” is insufficient. A resolver can reach any authoritative address. If one secondary serves an old chain while another serves the new generation, proofs, TTLs and cache state may differ even though all servers remain reachable. Activation authority belongs to the operator that can compare the fleet and retain a previously coherent signed generation for rollback.

Sources