DNSSEC Denial Proofs Let Resolvers Synthesize Negative Answers

A recursive resolver receives a query for a random subdomain beneath a signed zone and already holds a validated denial record from an earlier lookup. The queried label was never sent to the authoritative server, yet the resolver can still return an authenticated negative result. The answer is not a guess and is not ordinary exact-match negative caching. It is derived from cryptographic evidence that covers a portion of the DNS namespace.

That behavior is the operational effect of aggressive use of DNSSEC-validated cache, standardized in RFC 8198 and refined by RFC 9077. NSEC and NSEC3 records do more than prove one queried name absent. Under the applicable DNSSEC validation rules, they can establish absence across a range. A validating resolver can retain that evidence and apply it to later queries while the proof remains usable.

The optimization changes both query flow and failure boundaries. It reduces repeated traffic for names already covered by authenticated denial, but it also means authoritative changes can remain invisible to a resolver until cached denial material ceases to apply.

A denial record describes more than one failed lookup

Classic DNS negative caching stores an NXDOMAIN or NODATA result associated with a prior response. A later exact query can often be answered from that cache entry, avoiding another recursive resolution. That model still treats the negative answer largely as a result for a specific lookup.

NSEC exposes stronger structure. In a signed zone, an NSEC record links an existing owner name to the next existing owner name in canonical DNS name order and carries a bitmap of record types present at its owner. Together with a valid RRSIG and the DNSSEC chain of trust, that structure can prove that no owner name exists between two points, or that a particular type is absent at an existing name.

Suppose a signed zone has existing names that bracket delta.example in canonical order. A validated NSEC record covering that interval is evidence about the interval itself. If another queried name also falls inside the proven gap, a resolver does not need a new authoritative response merely to obtain the same fact again.

NSEC3 applies a related mechanism to hashed owner names. Its proof processing is more complex because validation must account for closest enclosers, next-closer names, wildcards, and the NSEC3 Opt-Out flag. The important boundary remains the same: synthesis is permitted only when cached validated material is sufficient to establish the required DNSSEC proof.

Validation is the authority behind synthesis

A resolver cannot safely treat arbitrary NSEC or NSEC3 data as permission to suppress upstream queries. RFC 8198 makes aggressive synthesis dependent on DNSSEC validation. Without that condition, forged denial records could become a broad cache-poisoning primitive: one injected range could suppress queries for names that actually exist.

The trust decision therefore occurs before the optimization. The resolver first establishes that the denial material is secure according to DNSSEC validation rules. Only then can the cache act as a source for later synthesized responses.

This distinction also separates authenticated denial from authoritative freshness. DNSSEC authenticates signed statements within their validity conditions; it does not promise that every resolver sees a zone change immediately. DNS already permits cached data to remain effective for a bounded period. Aggressive denial caching extends the set of queries that one cached proof can answer, so TTL handling becomes especially consequential.

RFC 9077 updates the TTL rules for NSEC and NSEC3 records and their use in aggressive caching. Resolver behavior must respect the effective lifetime of the proof rather than retaining denial evidence indefinitely simply because a signature has a later expiration time.

Range proofs change random-name traffic

Random-label query floods exploit a basic property of recursive DNS: a cache miss can force work toward authoritative infrastructure. If every generated label is unique, exact-match caching offers little relief because each name misses independently.

A validated NSEC range can alter that pattern. Once a resolver has a usable proof covering a range, later nonexistent names inside that range can be answered locally. The resolver avoids creating new upstream query state, and the authoritative server avoids receiving those covered lookups.

This is not a universal denial-of-service control. Coverage depends on the zone’s denial mechanism, the resolver’s validated cache contents, query distribution, TTLs, and NSEC3 details. A query outside cached proof ranges still requires normal resolution. Unsigned zones cannot supply DNSSEC-authenticated denial for this mechanism.

NSEC3 Opt-Out introduces another important limitation. A covering Opt-Out NSEC3 record does not, by itself, prove that every covered domain name is absent because insecure delegations can exist within an Opt-Out span. RFC 8198 therefore does not permit aggressive negative synthesis for a name when the available covering proof has that ambiguity.

Wildcards make the cache capable of positive synthesis

Aggressive DNSSEC caching is not limited to NXDOMAIN and NODATA. DNSSEC denial records also participate in proving wildcard applicability. If cached validated material establishes that the queried name does not exist and that a wildcard is the applicable source of synthesis, a resolver can construct a positive response from cached wildcard data under the specified conditions.

That behavior illustrates the deeper role of authenticated denial. A DNSSEC proof can establish the absence required to justify another naming rule. The resolver is not inventing zone content; it is combining validated cached statements according to DNS resolution and DNSSEC proof rules.

The constraint is strict. If the corresponding wildcard data is not available in cache, or the denial proof is insufficient, the resolver falls back to normal resolution. Aggressive caching is an optimization over evidence already held, not a license to infer beyond that evidence.

Newly added names can remain hidden behind valid cached proof

The most visible operational trade-off appears when a zone operator adds a name that falls inside a range previously proven empty. A validating resolver with an applicable cached denial proof can continue synthesizing a negative answer until that proof’s effective lifetime ends. It has no reason to contact the authoritative server during that interval.

This can surprise operators during rapid DNS changes. The authoritative zone may already contain the new record while some resolvers still possess valid evidence representing the earlier state. The condition resembles ordinary caching but can affect names that were never individually queried before the change.

For that reason, denial-record TTL policy is part of change-management policy. Long effective lifetimes reduce authoritative traffic and increase cache utility, but they also extend the interval during which additions can be masked by prior authenticated denial. Shorter lifetimes narrow that interval at the cost of more frequent upstream resolution.

Signature lifetime and cache lifetime are separate constraints. A cryptographic signature that remains temporally valid does not grant a resolver unlimited permission to keep serving a cached denial record after its effective TTL has expired.

NSEC3 obscures names but does not erase enumeration trade-offs

Plain NSEC records expose adjacent owner names directly, which allows zone contents to be enumerated by following the signed chain. NSEC3 was designed in part to make that process less direct by publishing hashes of owner names rather than the names themselves.

Hashing changes the disclosure property, but it does not turn the denial chain into confidential data. An observer can still collect NSEC3 records and test candidate names offline when those names are guessable. Iteration and salt parameters affect computation, and modern DNSSEC guidance constrains expensive parameter choices because they impose work on validators as well as on attackers.

That security trade-off is distinct from aggressive caching. A resolver can use either validated NSEC or suitable NSEC3 material for synthesis. The choice of denial format changes proof processing and information exposure, while the cache optimization changes when a resolver can avoid another authoritative query.

Cache state becomes part of the authoritative load boundary

Aggressive use of validated denial records moves work from repeated network resolution into local proof lookup. An implementation needs to locate covering NSEC or NSEC3 records efficiently, verify that cached material still satisfies the relevant proof conditions, and fall back to ordinary resolution when it does not.

That fallback matters. Failure to construct a valid proof is not evidence of nonexistence. An implementation error that converts uncertainty into a synthesized negative response can create availability failures for legitimate names. Conservative fallback preserves the distinction between absent evidence and evidence of absence.

The resulting architecture has a useful asymmetry. Validated cache state can suppress many redundant queries when it proves enough, while incomplete state still permits the resolver to consult authoritative servers. Security depends on keeping that asymmetry intact: synthesis follows authenticated proof, and every gap in proof returns the decision to normal DNS resolution.

Aggressive DNSSEC caching therefore changes more than performance. It turns signed denial material into reusable namespace evidence, making cache contents an active part of query routing, authoritative load, and change visibility. The optimization is safe only while the resolver preserves the validation, proof-coverage, and lifetime boundaries attached to that evidence.