]> Quad9

babak@farrokhi.net

Cloudflare

jabley@cloudflare.com

Cloudflare

sebastiaan@cloudflare.com

Operations and Management DNS EDE Extended DNS Errors DNSSEC NTA Negative Trust Anchor This document describes a mechanism for disclosing that a Negative Trust Anchor (NTA) was in effect at the time that a DNS response was generated, using an Extended DNS Error (EDE). Discussion Venues Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction defines the Extended DNS Error (EDE) mechanism, which allows DNS servers to encode additional information in a DNS response. defines the concept of a DNSSEC Negative Trust Anchor (NTA), an operational mechanism by which a validating resolver can be configured to temporarily disable DNSSEC validation for a specific domain to mitigate misconfiguration. A resolver with an NTA in effect might send a response that ordinarily would have been suppressed because of validation failures. This document defines a new EDE that can be sent within a response to indicate that the response was subject to an active NTA. A further goal of this signal is transparency toward end users and applications. recommends that operators disclose the NTAs they have in place, for example on a website, and notes that no in-band DNS signal exists to indicate that an NTA is in effect. This document defines that in-band signal, complementing such out-of-band disclosure.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document assumes a familiarity with common DNS terminology as described in .

Extended DNS Error Code 33 - Negative Trust Anchor in Effect A response that includes one or more instances of EDE 33 was generated with a covering NTA in effect. As with all EDEs, the EDE defined in this document is diagnostic; per a client MUST NOT use its presence to alter protocol processing. The inclusion of this EDE in a response does not change AD bit processing in DNS messages in any way. The only purpose of this EDE is to provide additional information about the response in which it appears. This EDE is intended for use in DNS responses sent by a DNS resolver with a configured NTA and MUST NOT be included in other responses. For example, a DNS response sent by an authoritative-only DNS server, which does not perform validation and hence has no obvious use for an NTA, SHOULD NOT include this EDE.

Operational Considerations An operator that applies an NTA SHOULD return this EDE in affected responses, so that end users and applications can tell that the response may not have been DNSSEC-validated. This complements, and does not replace, the disclosure recommended in . A response might be affected by an NTA for various reasons, not just in the case where the QNAME is subordinate to the domain for which an NTA has been configured. In any case, a resolver MAY include this EDE on any responses while an NTA is in effect, regardless of whether the presence of the NTA had a material effect on the contents of the response. A resolver with multiple NTAs in place simultaneously MAY include multiple instances of this EDE in a single response. Multiple instances of this EDE in a single response might each have different EXTRA-TEXT fields, for example, and might each describe a different active, applicable NTA. When multiple instances of this EDE are included in a response, the EXTRA-TEXT field in each instance MUST be populated. The operator MAY use the EXTRA-TEXT field to add context about the NTA, such as the name at which it was configured, the reason it was put in place, a reference where more information can be found, or its expected duration. As noted in , EXTRA-TEXT is intended for human consumption; operators SHOULD keep it readable and SHOULD NOT include private or sensitive information. Structured data MAY be included in the EXTRA-TEXT field, as described in . The JSON Names "d" and "t" have been registered for this purpose (see ) and should be used and interpreted when used with this EDE as follows:

JSON Name	Use and interpretation for this EDE
d	The domain name at which an active NTA has been configured
t	An indicative time at which this NTA might be expected to remain in place until

Note that it is usual for NTAs to be configured in response to unplanned events that have afflicted unaffiliated third parties, and hence consumers of structured EXTRA-TEXT should be interpret timestamps with generous flexibility.

IANA Considerations The IANA has made the following allocation in the "Extended DNS Error Codes" registry under the "Domain Name System (DNS) Parameters" registry group:

INFO-CODE	Purpose	Reference
33	Negative Trust Anchor	This document

The IANA is directed to update the "EXTRA-TEXT JSON Names" registry under the "Domain Name System (DNS) Parameters) registry group by adding the following entries:

JSON Name	Field Meaning	Description	Reference
d	domain-name	A fully-qualified domain name (in the case of an IDN, containing only A-labels) with no trailing period	This document
t	timestamp	A timestamp in format	This document

Security Considerations An NTA represents an intentional, operator-driven suspension of DNSSEC validation for a specific domain. See for further discussion of the operational and security implications of NTAs. The presence of the EDE defined in this document does not modify AD bit processing in DNS messages, and its only purpose is to provide additional information. EDEs encoded in DNS messages carry no cryptographic signatures and hence enjoy no inherent integrity protection. An on-path attacker could add, remove, or modify an EDE. Clients that require integrity protection of these signals should use a suitable mechanism, such as TSIG , SIG(0) or an authenticated and encrypted transport protocol such as DNS over TLS or DNS over HTTPS . See for more discussion.

References Normative References This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Citrix Systems, Inc. Nokia Open-Xchange Orange DNS filtering is widely deployed for various reasons, including network security and policy enforcement. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Informative References This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

Acknowledgements The authors acknowledge review and ideas from Carlos Horowicz, Mukund Sivaraman, Ralf Weber, Warren Kumari, Robert Edmonds and Petr Spacek.

Examples The following examples use configurations that exist in the DNS at the time of writing. Readers from the future may need to create analogous configurations in order to reproduce the results illustrated here. These examples were constructed using the well-known diagnostic tool dig, as shipped with BIND9. The output was hand-edited slightly to fit the formatting constraints of the document, but is otherwise consistent with the original output.

NTA in Effect, Valid DNSSEC Configuration The zone NTAMUCH.ORG is signed and an intact and functional path of trust exists back to the root zone. An NTA is applied to the domain NTAMUCH.ORG at the security-aware, validating resolver 1.1.1.1, but not at 9.9.9.9. > DiG 9.20.24 <<>> @1.1.1.1 NTAMUCH.ORG SOA +nocd +rec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 33: (a Negative Trust Anchor has been applied for this query ; (see RFC 7646)) ;; QUESTION SECTION: ;NTAMUCH.ORG. IN SOA ;; ANSWER SECTION: NTAMUCH.ORG. 1800 IN SOA barbara.ns.cloudflare.com. dns.cloudflare.com. ( 2407706086 ; serial 10000 ; refresh (2 hours 46 minutes 40 seconds) 2400 ; retry (40 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) ;; Query time: 21 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Fri Jun 26 10:49:10 CEST 2026 ;; MSG SIZE rcvd: 181 jabley@manta ~ % dig @9.9.9.9 NTAMUCH.ORG SOA +nocd +rec +multiline ; <<>> DiG 9.20.24 <<>> @9.9.9.9 NTAMUCH.ORG SOA +nocd +rec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7960 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;NTAMUCH.ORG. IN SOA ;; ANSWER SECTION: NTAMUCH.ORG. 1767 IN SOA barbara.ns.cloudflare.com. dns.cloudflare.com. ( 2407706086 ; serial 10000 ; refresh (2 hours 46 minutes 40 seconds) 2400 ; retry (40 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) ;; Query time: 11 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP) ;; WHEN: Fri Jun 26 10:49:20 CEST 2026 ;; MSG SIZE rcvd: 105 jabley@manta ~ % ]]>

NTA in Effect, Validation Problems Expected The zone BROKEN.NTAMUCH.ORG is delegated from the NTAMUCH.ORG zone using an accurate NS RRSet both sides of the zone cut, but a deliberately-fabricated DS RRSet at on the parent side. Records in the child zone are not signed, and no child zone DNSKEY RRSet exists. The effect is a secure delegation to an unsigned zone, a broken configuration that we should expect to trigger validation failures. The same NTA as described in the previous example is in place for the domain NTAMUCH.ORG on the resolver 1.1.1.1, but, again, not on the resolver 9.9.9.9. Both resolvers include different EDEs in the response which illustrate the problem, but note the different RCODEs: with the NTA in place, the 1.1.1.1 resolver returns an answer with NOERROR while the 9.9.9.9 resolver with no applicable NTA correctly returns RCODE SERVFAIL. > DiG 9.20.24 <<>> @1.1.1.1 BROKEN.NTAMUCH.ORG SOA +nocd +rec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25660 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for ; broken.ntamuch.org.) ; EDE: 33: (a Negative Trust Anchor has been applied for this ; query (see RFC 7646)) ;; QUESTION SECTION: ;BROKEN.NTAMUCH.ORG. IN SOA ;; ANSWER SECTION: BROKEN.NTAMUCH.ORG. 300 IN SOA maleah.ns.cloudflare.com. dns.cloudflare.com. ( 2407705944 ; serial 10000 ; refresh (2 hours 46 minutes 40 seconds) 2400 ; retry (40 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) ;; Query time: 20 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Fri Jun 26 10:52:52 CEST 2026 ;; MSG SIZE rcvd: 245 jabley@manta ~ % dig @9.9.9.9 BROKEN.NTAMUCH.ORG SOA +nocd +rec +multiline ; <<>> DiG 9.20.24 <<>> @9.9.9.9 BROKEN.NTAMUCH.ORG SOA +nocd +rec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20047 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing) ;; QUESTION SECTION: ;BROKEN.NTAMUCH.ORG. IN SOA ;; Query time: 116 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP) ;; WHEN: Fri Jun 26 10:53:05 CEST 2026 ;; MSG SIZE rcvd: 53 jabley@manta ~ % ]]>