Summary

  • RFC 5155 allows qualifying unsigned delegations to be omitted from an NSEC3 chain when the covering record has the Opt-Out flag.
  • A covering Opt-Out record does not assert whether those insecure delegations exist; it authenticates a narrower denial statement.
  • A secure delegation requires a signed DS RRset and a validated chain, not merely a valid NSEC3 signature somewhere around the queried hash.
  • Operators need a delegation-specific receipt that preserves secure, insecure and indeterminate outcomes instead of collapsing them into “DNSSEC passed.”

Imagine a resolver trace in which every RRSIG validates, the NSEC3 hashes line up and the result is marked green. An audit export later turns that green line into “child delegation secured.” Yet the queried name falls in an Opt-Out interval. The proof was authentic; the conclusion was too broad.

This is a hypothetical trace, not an incident attributed to a registry or operator. The failure is one of scope: cryptographic validity does not expand what the signed record actually asserts.

What Opt-Out changes

RFC 5155 defines NSEC3 as a hashed form of authenticated denial of existence. Instead of listing clear owner names in canonical order, a zone signs records whose owner names and next-owner references occupy a hash-ordered chain.

For delegation-heavy zones, maintaining an NSEC3 record and signature for every unsigned child can be costly. Opt-Out permits the owner names of qualifying insecure delegations to be excluded. A record with its Opt-Out flag set may span zero or more such delegations, allowing them to be added or removed without rebuilding that part of the chain.

That operational economy changes the proof. RFC 5155 says an Opt-Out NSEC3 record does not assert the existence or non-existence of the insecure delegations it may cover. It still makes authenticated statements about other authoritative data in the span, but the covered unsigned delegation is deliberately outside the full cryptographic inventory.

A valid proof can end in “insecure”

The parent-side evidence at a delegation matters. RFC 5155 distinguishes a secure delegation—an NS RRset with a signed DS RRset—from an insecure one that has the NS RRset but no DS RRset. The DS record is what connects the parent’s authenticated data to the child’s DNSKEY.

An RRSIG that validates the covering NSEC3 record proves that the parent signed that NSEC3 statement. It does not manufacture a DS record for a covered child. Nor does the Opt-Out bit by itself say that a particular delegation exists. RFC 7129 makes the consequence direct: Opt-Out NSEC3 records cannot prove or deny the existence of the insecure delegations they cover, and those delegations do not receive DNSSEC’s cryptographic protection.

The resolver’s classification therefore needs more than a green cryptographic primitive. It must identify the delegation point, locate or authenticate the absence of DS, evaluate the relevant NSEC3 proof, continue validation where a chain exists and preserve the difference between secure, insecure, bogus and indeterminate results.

Keep proof scope attached to the result

Evidence should name the exact query, response code, zone and delegation point. For NSEC3, preserve the hash algorithm, iterations, salt, owner hash, next hashed owner, type bitmap and Opt-Out flag. Record the closest provable encloser material when it is part of the denial, along with every DNSKEY and RRSIG validation outcome and the trust anchor used.

Cache state and time matter too. A valid proof is bounded by TTLs, signature inception and expiration, parent publication and resolver cache. A later DS change can alter the delegation’s security state even while an older observation remains in an audit store.

The defensible statement is specific: this signed NSEC3 response validated for this query and supported this secure or insecure classification at this time. “The delegation is secured because NSEC3 validated” is not the same claim.