Summary

  • DNSSEC turned a negative DNS answer into verifiable evidence by signing the ordered boundaries around names and record types that are absent.
  • NSEC3, Opt-Out and validated-cache synthesis do not merely tune a protocol; they allocate disclosure, computation, delegation assurance and the time at which a new name can begin to work.

Imagine asking an archive for a file that is not there. A signature on every file proves the files are genuine, but it does not prove the clerk has not hidden the one you requested. To authenticate absence, the archive needs a signed catalogue whose ordering makes the gap visible.

That is the conceptual move behind DNSSEC’s denial of existence.

Ordinary DNS can return NXDOMAIN when a name does not exist, or a “no data” answer when the name exists but the requested record type does not. Without DNSSEC validation, either answer is only as trustworthy as the response path. An on-path adversary may prefer a forged absence to a forged address: making a service disappear can be enough.

RFC 4034 gave a signed zone a way to describe its gaps. An NSEC record names the next authoritative owner in the zone’s canonical order and carries a bitmap of record types present at its own name. RFC 4035 then defines how a validator uses authenticated NSEC records. If a queried name falls between two signed boundaries, the interval proves there is no exact name there. If the name exists but the requested type is missing from the signed bitmap, the proof is about the absent type. A name error must also rule out a wildcard that could have supplied an answer.

The important entity is not a special negative record for every possible question. That would be impossible: the space of possible labels is vast. The proof is the ordered interval. Two authenticated facts bound an empty space.

The first proof disclosed too much

NSEC’s clarity creates a second property. Because each record points to the next authoritative name, a patient querier can follow the chain. The mechanism that proves a gap can also reveal the catalogue.

This “zone walking” does not expose secret data that DNS was designed to encrypt; DNS publishes names so they can be used. Yet an easily enumerated list may still disclose naming patterns, internal-looking service labels or a useful reconnaissance map that was previously expensive to assemble. The IETF therefore faced a structural tension: a validator needs evidence strong enough to bound absence, while a zone operator may not want to hand every visitor a plain ordered index.

RFC 5155 introduced NSEC3. It keeps the chain idea but replaces directly readable owner names with hashed names. A validator can still establish that a hashed query lies within a signed range. An enumerator sees a chain of hashes and must guess candidate labels offline.

That is friction, not secrecy. Common DNS labels are predictable, appear in certificates, logs and links, and can be tested against the chain. The current operational guidance in RFC 9276 is explicit about the diminishing return: more hash iterations increase work for authoritative servers and validators without turning guessable names into confidential information.

Opt-Out prices scale into the proof

Large delegation-heavy zones created another cost. If most child delegations are unsigned, constructing and updating an NSEC3 record for every one can create substantial signing and memory work. NSEC3 Opt-Out allows spans to cover insecure delegations without giving each delegation its own hashed record.

The saving is real, and so is the semantic concession. RFC 5155 says an Opt-Out span does not assert whether an insecure delegation inside it exists. It still protects other authoritative data, but the proof is deliberately less complete at that boundary. The zone gains cheaper, faster delegation changes by declining to offer the same authenticated statement about every unsigned child.

That makes Opt-Out a governance choice as much as a server option. It decides which absence claims the operator is prepared to stand behind cryptographically. RFC 9276 consequently discourages Opt-Out for small zones and reserves its plausible use for very large, dynamic and sparsely signed delegation zones.

A cached gap can answer future questions

The proof later acquired leverage beyond the query that fetched it. RFC 8198 permits a validating resolver to use cached NSEC or NSEC3 ranges aggressively. If a later question falls inside a range already proved empty, the resolver can synthesize the negative answer without asking the authoritative server again.

This can reduce latency, authoritative load and the number of useless or privacy-revealing queries sent upstream. It can also absorb part of a random-label denial-of-service pattern. But the cache is now applying a signed statement to future questions, so the statement’s lifetime matters operationally.

RFC 8198 notes that NSEC or NSEC3 TTLs, together with the zone’s negative-caching values, express how quickly a newly added name can begin to work. A deployment team that creates a name immediately after publishing a broad proof of absence may discover that validating resolvers are still entitled to answer “no” from cache. The protocol is behaving correctly; the change plan ignored the validity window of the negative evidence.

Simpler parameters are now the stronger practice

The historical arc ends in restraint. RFC 9276 recommends NSEC when NSEC3’s features are not needed. If NSEC3 is required, it mandates zero additional iterations and recommends an empty salt. Extra iterations impose computation on every validating party, amplify CPU-exhaustion risk and may produce interoperability failures; a static salt adds little because the fully qualified name already makes the work zone-specific.

The RFC also asks operators to verify known nonexistent labels against secondary servers after changing parameters. That test is unusually revealing. Positive records can look healthy while the negative-proof chain is stale, mismatched or too expensive for one serving implementation. A zone is not fully signed if its “nothing here” answers cannot be validated consistently.

None of these RFCs proves that a particular operator has deployed NSEC, NSEC3 or Opt-Out correctly. They define the mechanism and current practice. Deployment quality must be measured at the actual authoritative and validating edges.

Sources