Negative Caching of DNS Resolution Failures
updates
Extracted elements (27)
Aggressive requerying by recursive resolvers during resolution failures has been empirically documented at massive scale: the 2018 DNSSEC KSK rollover caused an 80x increase (to 1.2 billion/day) in DNSKEY queries to root servers, and during the 2021 Facebook outage, .COM/.NET query traffic rose from 7,000 to 900,000 queries per second, motivating mandatory negative caching.
Implementation details for the resolution failure cache are intentionally unspecified: different failure conditions may be cached differently (e.g., DNSSEC failures keyed on name/class/type, unresponsive servers keyed only on IP address). Developers should document their choices so operators know expected behavior.
The 5-minute maximum cache duration for resolution failures (inherited from RFC 2308) is intentionally short to limit the impact of cache poisoning attacks that inject forged failure messages, since an attacker would need sustained spoofing throughout the backoff period and repeated attacks due to cache expiry.
Resolvers not joining multiple outstanding queries for the same <name, type, class> tuple are more susceptible to Birthday Attacks (RFC 5452 Section 5), particularly when those queries result in timeouts, because multiple outstanding queries make it easier for attackers to match DNS message parameters.
The term 'DNS transport' in this document covers classic DNS-over-UDP and DNS-over-TCP (RFC 1034, RFC 7766) as well as encrypted transports including DNS-over-TLS (RFC 7858), DNS-over-HTTPS (RFC 8484), and DNS-over-QUIC (RFC 9250). Retry-count limits apply per transport type to the same server address.
This document updates RFC 2308 to require (rather than permit) negative caching for all DNS resolution failure conditions, updates RFC 4035 to require (rather than allow) caching of DNSSEC validation failures, and updates RFC 4697 to expand the anti-requerying prohibition from NS queries at the parent zone to all query types and all ancestor zones.
A resolver MAY retry a given query over a different DNS transport to the same server if it has reason to believe that transport is available and compatible with its security policies.
A resolver MUST NOT retry a given query to a server address over a given DNS transport more than twice (three queries total) before considering the server address unresponsive over that transport for that query.
Resolvers MUST cache resolution failures for at least 1 second and MUST NOT cache them for longer than 5 minutes, consistent with RFC 2308.
Resolvers MUST implement a cache for resolution failures to eliminate repeated upstream queries that cannot be resolved.
Resolvers SHOULD employ an exponential or linear backoff algorithm to increase the cache duration for persistent resolution failures, up to a configurable maximum not exceeding 5 minutes.
Resolvers SHOULD implement measures to mitigate resource exhaustion attacks on the failed resolution cache by limiting memory and/or processing time devoted to this cache.
Security-aware resolvers MUST cache DNSSEC validation failures (with restrictions on TTL). This strengthens RFC 4035 Section 4.7, which previously allowed caching with MAY.
The minimum cache duration for resolution failures SHOULD be configurable by the operator, balancing reduced query load against recovery time from transitory issues.
Upon encountering a zone whose name servers are all non-responsive, a resolver MUST cache the resolution failure and MUST limit queries to the non-responsive zone's parent zone (and all ancestor zones) just as it limits subsequent queries to the non-responsive zone itself. This updates RFC 4697 Section 2.1.1 to apply to all query types and all ancestor zones.
When an incoming query matches a cached resolution failure, the resolver MUST NOT send any corresponding outgoing queries until after the cache entries expire.
This specification has no impact on user privacy.
A delegation loop occurs when two or more domains circularly reference each other's name servers in their NS RRsets, making all names under the involved zones unresolvable. Undetected loops can generate DDoS-level traffic (TsuNAME vulnerability).
A DNS resolution failure occurs when none of the servers available to a resolver provide any useful response (requested data, referral, or indication of non-existence) for a given <name, type, class> query tuple. NXDOMAIN and NOERROR/NODATA are not resolution failures.
A DNSSEC validation failure occurs when a security-aware resolver cannot establish a chain of trust for an RRset after trying multiple authoritative servers; causes include signature mismatch, missing DNSKEY RRs, denial-of-existence issues, and clock skew.
An alias loop occurs when CNAME or DNAME records form a circular chain. RFC 1034 Section 3.6.2 requires that resolver software detect and signal CNAME loops as errors rather than failing silently.
FORMERR (RCODE=3) is returned when a server cannot interpret the query; most commonly associated with EDNS(0) processing problems. Some recursive clients retry without EDNS(0) upon receiving FORMERR; resolution failures from FORMERR are rare.
REFUSED (RCODE=5) is returned when a server declines to process a query for policy reasons, such as non-authoritative queries to an authoritative server or out-of-ACL sources to a recursive resolver.
SERVFAIL (RCODE=2) is returned when a name server cannot process a query due to its own problems; authoritative servers use it when they lack valid zone data, and recursive servers use it for a variety of failure conditions including those described in this document.
Timeouts and unreachable servers (collectively 'dead/unreachable servers' per RFC 2308) include ICMP port unreachable, TCP connection refused, TLS handshake failure, and lack of response within a timeout period. Resolvers may have both a retry-trigger timeout and a larger server-unresponsive timeout.
A cache poisoning denial-of-service attack is possible because failure messages cannot be DNSSEC-signed: an attacker can forge SERVFAIL or similar responses to cause resolvers to stop querying authoritative servers. This attack requires sustained spoofing and is mitigated by the 5-minute cache limit, making effects localized and time-bounded.
An attacker may attempt a resource exhaustion attack by sending queries for a large number of names and/or types that all result in resolution failure, exhausting the resolver's failure cache memory. Resolvers SHOULD bound memory devoted to this cache.