Add TTLs to DNS errors
draft-homburg-dnsop-dettl-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| 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]