Skip to main content

Add TTLs to DNS errors
draft-homburg-dnsop-dettl-00

Document Type Active Internet-Draft (individual)
Author Philip Homburg
Last updated 2026-06-19
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-homburg-dnsop-dettl-00
DNSOP                                                       P.C. Homburg
Internet-Draft                                              19 June 2026
Updates: 9520 (if approved)                                             
Intended status: Standards Track                                        
Expires: 21 December 2026

                         Add TTLs to DNS errors
                      draft-homburg-dnsop-dettl-00

Abstract

   When a DNS server replies an error other than NXDOMAIN, there is no
   mechanism to specify how long this error can be cached by the
   recepient.  This document introduces a mechanism where a server can
   specify the time to live (TTL) of an error by adding a SOA record to
   the additional section of a reply.  Clients can use this TTL at their
   discretion.  In particular, clients can limit the TTL to a maximum
   value, impose a minimum value or just ignore the TTL value all
   together.

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

Homburg                 Expires 21 December 2026                [Page 1]
Internet-Draft                    dettl                        June 2026

   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 . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Server behavior . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Client behavior . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

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
   (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.

Homburg                 Expires 21 December 2026                [Page 2]
Internet-Draft                    dettl                        June 2026

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:

                +=========+============+=================+
                | RR TYPE | _NODE NAME |       Reference |
                +=========+============+=================+
                | SOA     | _error_ttl | (This document) |
                +---------+------------+-----------------+

                                 Table 1

Homburg                 Expires 21 December 2026                [Page 3]
Internet-Draft                    dettl                        June 2026

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.

7.  Informative References

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/info/rfc8552>.

   [RFC9520]  Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
              of DNS Resolution Failures", RFC 9520,
              DOI 10.17487/RFC9520, December 2023,
              <https://www.rfc-editor.org/info/rfc9520>.

Author's Address

   Philip Homburg
   Email: philip@nlnetlabs.nl

Homburg                 Expires 21 December 2026                [Page 4]