Add TTLs to DNS errors

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 .¶

2. Introduction

Typically, caching of errors other than NXDOMAIN is conservative compared to caching of other DNS replies. [RFC9520], Section 3.2, 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.¶

3. 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.¶

4. 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.¶

5. IANA Considerations

Per [RFC8552], IANA is directed to add the following entry to the DNS Underscore Global Scoped Entry Registry:¶

6. 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.¶

Author's Address