Add TTLs to DNS errors

Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://codeberg.org/NLnetLabs/draft-homburg-dnsop-dettl .

Introduction Typically, caching of errors other than NXDOMAIN is conservative compared to caching of other DNS replies. , , requires that errors such as SERVFAIL be cached for at least 1 second and at most 5 minutes. The effect of this is that if all nameservers of a DNS zone experience an error and start replying SERVFAIL, then the load on those servers increases. This may prevent or delay recovery from such a condition. This also prevents introduction of new protocol elements where authoritative servers intenionally return a SERVFAIL for certain queries. Similar effects occur between a stub-resolver and a recursive resolver. When a DNSSEC validating resolver returns SERVFAIL as a result of a DNSSEC validation error, it may know (based on the TTLs of the RRsets that cause the error) how long this error can be cached. Another example is a proposal to use a delegation to the root (NS .) to indicate that a name exists but is not served by any name servers. A recursive resolver can return SERVFAIL for such names and knows (based on the TTL of the NS RRset or the negative replies for the A and AAAA queries) how long the SERVFAIL can be cached.

Server behavior When a DNS server replies with an error other than NXDOMAIN, the server should add a SOA record to the additional section of the reply. In this case, the server SHOULD keep the Answer and Authority sections empty and the SOA record SHOULD be the first record of the additional section. The SOA record MUST have "_error_ttl." as owner name, and as TTL the time to live of the error. MNAME and RNAME SHOULD be set to ".". SERIAL, REFRESH, RETRY, and EXPIRE SHOULD be set to 0. For compatibility with existing SOA processing for NXDOMAIN and NODATA, the MINIMUM field SHOULD be set to the TTL of the SOA record.

Client behavior A DNS client MAY take a TTL as specified in this document into account or follow the behavior outlined in RFC 9520. This document updates RFC 9520 in that a client that uses a TTL as described in this document may exceed the 5 minute limit. A client MAY stop the processing described in this draft if the Answer and Authority sections are not empty or if the first record in the Additional section is not a SOA record. Clients should take care to limit TTL values. The TTL value cannot be protected using DNSSEC. With insecure transports, an attacker can spoof an error reply with a high TTL. Client may also impose a minimum value. This minimum SHOULD be less than 5 minutes.

IANA Considerations Per , IANA is directed to add the following entry to the DNS Underscore Global Scoped Entry Registry:

RR TYPE	_NODE NAME	Reference
SOA	_error_ttl	(This document)

Security Considerations This document addresses the issue that a nameserver that return errors other than NXDOMAIN will often see client cache responses for a much shorter time than typical resposenses. This increases the load of the nameserver and may result in generally lower performance or availablity of the service. In particular if the errors are returned due to a failure, this increase load may make it harder to recover from failures. This document makes it possible that servers and clients coordinate to keep the load at reasonable levels.