Summary

  • NSEC and NSEC3 authenticate specific negative statements about the contents of a signed zone. The proof is tied to a signer, zone, query, algorithm, TTL and signature-validity interval.
  • NSEC3 Opt-Out deliberately permits unsigned delegations to fall inside a covered interval. A validating resolver may prove an insecure delegation path without receiving proof that every skipped name is absent.

The signed answer that says less than “never existed”

A resolver asks for an address record at a label that is not present. An authoritative server returns NXDOMAIN, or it returns NOERROR with no record of the requested type. In an unsigned zone, the negative answer rests on the authority of the responding server and the security of the path. In a signed zone, NSEC or NSEC3 records can let a validating resolver test the absence cryptographically.

That is a major improvement. An attacker cannot simply replace a positive answer with a forged negative one and expect a validating resolver to accept it. The resolver can verify the chain of trust, the signatures and the denial proof.

But “authenticated denial of existence” is a protocol term, not a metaphysical claim. RFC 4035 says an authenticated NSEC can prove that an RRset is not present in a signed zone. The zone qualifier matters. The proof describes the data committed by that zone’s signer during the signature’s valid life. It does not search every database, recover the operator’s intention or decide rights in the label.

A name can be absent because no one registered it, because a registration expired, because a registry placed it on hold, because a provisioning system failed, because a delegation moved, or because a signer published an incorrect zone. DNSSEC distinguishes a validated statement from an unauthenticated one. It does not choose among those causes.

NSEC turns order into evidence

NSEC records link existing owner names in canonical order. Each record names the next owner and carries a bitmap of record types present at its own owner name. A signed interval can therefore prove that no exact owner name lies between its two endpoints. A bitmap can prove that a name exists but lacks the requested type.

These are different negative statements. NXDOMAIN means the queried name does not exist in the relevant DNS tree position. NODATA means the name exists but the requested record type does not. An empty non-terminal can have descendants even though it owns no RRset itself. Wildcards add another question: a server must prove not only the absence of an exact match but also the absence of a closer wildcard source where the protocol requires it.

The proof is consequently a small argument, not a boolean stamped “missing”. A validator asks which zone should have contained the answer, which NSEC interval covers the name, which bitmap covers the type, whether a wildcard could have supplied it, and whether every signature and key link validates.

NSEC also makes the zone’s ordered names discoverable. Repeated queries can walk the chain. That operational disclosure helped motivate NSEC3, but the visibility is itself instructive: a cryptographic commitment can provide strong verifiability while revealing more structure than the operator intended.

NSEC3 hashes names but preserves an ordered commitment

NSEC3 replaces clear owner names with hashes calculated using published parameters. A resolver hashes the relevant names and compares them with signed intervals. This makes casual zone enumeration harder, but it does not make the names secret. Guessable labels can be tested offline, and the ordered hash chain still exposes a bounded commitment surface.

The IANA NSEC3 registry currently lists SHA-1 as hash algorithm 1 and no second assigned hash algorithm. RFC 9276 responds to the real economics of that design: additional iterations raise authoritative signing and validating cost while providing little protection against modern offline guessing. Its operational guidance is to use zero iterations and an empty salt in ordinary deployments, and to prefer NSEC where zone enumeration is not a concern.

This is a governance lesson in minimum mechanisms. A parameter may look like a stronger privacy dial while merely relocating cost to every signer and validator. The relevant question is not whether a number is larger, but whether running code creates additional security at acceptable shared cost.

Opt-Out means an interval can contain an unsigned delegation

Large delegation-centric zones faced another cost. If every insecure child delegation required its own NSEC3 and signature, signing a large parent zone would create substantial extra data. NSEC3 Opt-Out permits certain insecure delegations and their derived empty non-terminals to be omitted from the NSEC3 chain.

The Opt-Out flag changes what a covering record can prove. RFC 7129 states the boundary directly: an Opt-Out NSEC3 record cannot prove or deny the existence of names that fall within its interval. The validator may use the proof to establish that no DS record secures the delegation and then treat the child as insecure, but it must not promote the interval into a claim that every skipped label is nonexistent.

This distinction is easy to lose in dashboards. A monitoring system may see a valid NSEC3 proof, display a green “authenticated” badge and store name_absent=true. Under Opt-Out, the correct record may be closer to: a signed parent interval covers this hash; the interval is Opt-Out; no authenticated DS was established for the candidate delegation; existence of skipped insecure delegations is not decided by this covering record alone.

The difference matters during incident response. A disputed child can be operationally delegated without a DS and still sit inside an Opt-Out span. A parent-zone proof does not settle whether the registry intended the delegation, whether the child is active everywhere, or whether a provisioning transaction should be reversed.

Caches may answer without asking the authority again

Negative evidence travels. RFC 2308 defines negative caching. RFC 8020 allows an NXDOMAIN cut: when a resolver accepts that a name does not exist, it can treat names below that node as unreachable for the bounded cache lifetime. RFC 8198 goes further for validating resolvers, allowing them to synthesize negative answers from cached NSEC or NSEC3 intervals.

This reduces latency, authoritative load and the privacy leakage caused by repeated queries. It also creates a custody question. A user may receive a negative answer that the recursive resolver synthesized without a fresh query to the authoritative server. The answer can still be valid because the cached proof remains within its TTL and signature interval. Yet it is evidence about the signed state represented by that cached material, not proof that the authoritative zone has not changed since the material was obtained.

Operators therefore need timestamps and provenance. Record whether the denial came directly from an authority or was synthesized, which proof records supported it, when they were received, their TTLs, signature inception and expiration, closest-encloser calculation, wildcard proof, Opt-Out status and validation chain. A screenshot of NXDOMAIN lacks almost every fact needed for later accountability.

A negative answer is not a deletion order

The institutional boundary is sharper than the technical one. A registry or authoritative operator controls what is published in its zone. A registrar may control a registration transaction. A registrant may have contractual rights. A dispute panel or court may issue a defined remedy. A recursive resolver controls its cache and validation policy. None of those actors acquires the powers of the others merely because a signed denial exists.

The proof does not say that a deleted name was lawfully deleted. It does not show that notice was sent, payment failed, eligibility ended or an appeal was exhausted. It does not prove that a person never held the name. It does not authorize a third party to register the label. It does not make the signer the owner of the underlying claim.

The proper audit trail joins, without collapsing, at least four records: the registration or entitlement record; the provisioning decision and its authorization; the signed zone version; and observations made by validating resolvers. The signed zone is the operative public layer. The other records explain how it came to be and whether it should change.

The thin common ledger

Heng Lu’s minimum-layer doctrine offers the clean division. The globally shared layer needs enough information for resolvers to distinguish validated data, validated absence, insecure delegation and bogus evidence. It does not need a global court of naming entitlement.

Running code remains primary. The actual zone cut, DNSKEY and DS chain, NSEC or NSEC3 parameters, signed intervals, Opt-Out flag, wildcard state, TTL, signature window and resolver behavior decide the technical result. Policy prose cannot turn a bogus proof into a valid one, and a valid proof cannot turn policy prose into a legal mandate.

The durable formulation is narrow: DNSSEC can authenticate what a signed zone did not contain at a bounded time and under defined proof rules. It cannot decide why the absence occurred or who deserves the name. Preserving that boundary strengthens both cryptographic trust and institutional accountability.

Sources