Aggressive Use of DNSSEC-Validated Cache
updated by
- rfc-9077 — NSEC and NSEC3: TTLs and Aggressive Use
updates
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
Extracted elements (20)
Aggressive negative caching was first proposed in RFC 5074 (DNSSEC Lookaside Validation) to efficiently find covering NSEC records. This document generalizes the technique to all DNSSEC-validating resolvers to reduce latency, resource utilization, and privacy leakage.
RFC 4035 Section 4.5 previously recommended against synthesizing answers from NSEC/wildcard records to avoid blocking new authoritative data. This document relaxes that recommendation because, even without this technique, an exact-name lookup could result in a cached negative answer during the same interval — so zone operators already cannot expect newly added names to be usable immediately.
With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field become the authoritative statement of how quickly a newly added name can start working within a zone, making the prior recommendation against synthesis unnecessary.
Aggressive negative caching changes cache indexing: in addition to exact QNAME/QCLASS/QTYPE/CD-bit lookups, the validator checks whether any cached validated NSEC record covers the sought record. Synthesized negative answers must not be returned when the CD bit was set on the incoming query.
The negative cache TTL is taken from the minimum of SOA.MINIMUM and SOA's TTL (per RFC 2308), which can be less than the TTL of NSEC/NSEC3 records. Resolvers must use this minimum rather than the NSEC/NSEC3 record TTL directly to avoid serving stale negative answers.
A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority section of a negative response, if SOA.MINIMUM is smaller.
As long as the validating resolver can determine that a name would not exist without the wildcard match, it SHOULD synthesize an answer (or NODATA response) for that name using the cache-deduced wildcard. If the corresponding wildcard record is not in the cache, it MUST fall back to query authoritative DNS servers.
If a covering NSEC3 RR has an Opt-Out flag, the covering NSEC3 RR does not prove the non-existence of the domain name and aggressive negative caching is not possible for that domain name.
If denial of existence can be determined using NSEC records in the cache according to RFC 4035 Section 5.4 rules, then the resolver can immediately return an NXDOMAIN or NODATA response without querying authoritative servers.
If errors happen in an aggressive negative caching algorithm, resolvers MUST fall back to resolve the query as usual, processing the query as though aggressive negative caching is not implemented.
If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3, and wildcard records to synthesize answers. Otherwise, it MUST fall back to send the query to the authoritative DNS servers.
It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to 10800 seconds (3 hours), consistent with RFC 2308's suggested maximum default negative cache TTL.
NSEC resource records provide authenticated denial of existence by specifying names that appear alphabetically before and after the queried-for name in a DNSSEC-signed zone. A validating resolver can use a cached NSEC record to answer NXDOMAIN for any query name falling within its covered range.
NSEC3 resource records provide hashed authenticated denial of existence. Aggressive NSEC3 caching requires checking non-terminals and wildcards derived from query names, and is inapplicable when a covering NSEC3 RR has the Opt-Out flag set.
The NSEC_TABLE is an ordered data structure of NSEC and NSEC3 records indexed by signer domain name, needed by validators implementing aggressive negative caching to efficiently find covering NSEC/NSEC3 records for a given query name.
The procedure for determining ENT (empty non-terminal) vs. NXDOMAIN using NSEC requires verifying the record is secure, checking sort order of the given name relative to the NSEC owner and next domain name, and detecting parent-zone NSEC records via NS/SOA bit combination.
Wildcard records in DNSSEC-signed zones can be used by validating resolvers to synthesize positive answers for names not explicitly present in the zone, provided the resolver can determine that the name would not exist without the wildcard match.
An attacker who can successfully spoof responses may poison a cache with old NSEC/NSEC3 records whose RRSIG expiration time is far in the future (weeks). With aggressive NSEC/NSEC3 use, one successful cache-poisoning attack can suppress many queries for new names up to the negative TTL, whereas without this technique the attacker must repeat the attack for every query.
The technique may help mitigate 'random QNAME attacks' where attackers send many queries for random subdomains, causing DoS on authoritative servers. A resolver using aggressive caching can answer directly from cache for random queries falling within already-requested NSEC ranges, though coverage is limited to DNSSEC-signed zones.
Use of NSEC/NSEC3 resource records without DNSSEC validation may create serious security issues; this technique requires DNSSEC validation before synthesizing answers from cached denial-of-existence records.