ICANN

roy.arends@icann.org

ICANN

matt.larson@icann.org

OPS dnsop DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 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 () 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

• .  Introduction
• .  Requirements Notation
• .  Terminology
• .  Overview
  • .  Example
• .  EDNS0 Option Specification
• .  DNS Error Reporting Specification
  • .  Reporting Resolver Specification
    • .  Constructing the Report Query
  • .  Authoritative Server Specification
  • .  Monitoring Agent Specification
• .  IANA Considerations
• .  Operational Considerations
  • .  Choosing an Agent Domain
  • .  Managing Caching Optimizations
• .  Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction When an authoritative server serves a stale DNSSEC-signed zone, the cryptographic signatures over the resource record sets (RRsets) may have lapsed. A validating resolver will fail to validate these resource records. Similarly, when there is a mismatch between the Delegation Signer (DS) records at a parent zone and the key signing key at the child zone, a validating resolver will fail to authenticate records in the child zone. These are two of several failure scenarios that may go unnoticed for some time by the operator of a zone. Today, there is no direct relationship between operators of validating resolvers and authoritative servers. Outages are often noticed indirectly by end users and reported via email or social media (if reported at all). When records fail to validate, there is no facility to report this failure in an automated way. If there is any indication that an error or warning has happened, it may be buried in log files of the resolver or not logged at all. This document describes a method that can be used by validating resolvers to report DNSSEC validation errors in an automated way. It allows an authoritative server to announce a monitoring agent to which validating resolvers can report issues if those resolvers are configured to do so. The burden to report a failure falls on the validating resolver. It is important that the effort needed to report failure is low, with minimal impact to its main functions. To accomplish this goal, the DNS itself is utilized to report the error.

Requirements Notation 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.

Terminology This document uses DNS terminology defined in BCP 219 . This document also defines and uses the following terms:

Reporting resolver:

A validating resolver that supports DNS error reporting.

Report query:

The DNS query used to report an error. A report query is for a DNS TXT resource record type. The content of the error report is encoded in the QNAME of a DNS request to the monitoring agent.

Monitoring agent:

An authoritative server that receives and responds to report queries. This facility is indicated by a domain name, referred to as the "agent domain".

Agent domain:

A domain name that is returned in the EDNS0 Report-Channel option and indicates where DNS resolvers can send error reports.

Overview An authoritative server indicates support for DNS error reporting by including an EDNS0 Report-Channel option with OPTION-CODE 18 and the agent domain in the response. The agent domain is a fully qualified, uncompressed domain name in DNS wire format. The authoritative server MUST NOT include this option in the response if the configured agent domain is empty or is the null label (which would indicate the DNS root). The authoritative server includes the EDNS0 Report-Channel option unsolicited. That is, the option is included in a response despite the EDNS0 Report-Channel option being absent in the request. If the authoritative server has indicated support for DNS error reporting and there is an issue that can be reported via extended DNS errors, the reporting resolver encodes the error report in the QNAME of the report query. The reporting resolver builds this QNAME by concatenating the "_er" label, the QTYPE, the QNAME that resulted in failure, the extended DNS error code (as described in ), the label "_er" again, and the agent domain. See the example in and the specification in . Note that a regular RCODE is not included because the RCODE is not relevant to the extended DNS error code. The resulting report query is sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver. The report query will ultimately arrive at the monitoring agent. A response is returned by the monitoring agent, which in turn can be cached by the reporting resolver. This caching is essential. It dampens the number of report queries sent by a reporting resolver for the same problem (that is, with caching, one report query per TTL is sent). However, certain optimizations, such as those described in and , may reduce the number of error report queries as well. This document gives no guidance on the content of the RDATA in the TXT resource record.

Example A query for "broken.test.", type A, is sent by a reporting resolver. The domain "test." is hosted on a set of authoritative servers. One of these authoritative servers serves a stale version of the "test." zone. This authoritative server has an agent domain configured as "a01.agent-domain.example.". The authoritative server with the stale "test." zone receives the request for "broken.test.". It returns a response that includes the EDNS0 Report-Channel option with the domain name "a01.agent-domain.example.". The reporting resolver is unable to validate the "broken.test." RRset for type A (an RR type with value 1), due to an RRSIG record with an expired signature. The reporting resolver constructs the QNAME "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it. This QNAME indicates extended DNS error 7 occurred while trying to validate "broken.test." for a type A (an RR type with value 1) record. When this query is received at the monitoring agent (the operators of the authoritative server for "a01.agent-domain.example."), the agent can determine the "test." zone contained an expired signature record (extended DNS error 7) for type A for the domain name "broken.test.". The monitoring agent can contact the operators of "test." to fix the issue.

EDNS0 Option Specification This method uses an EDNS0 option to indicate the agent domain in DNS responses. The option is structured as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION-CODE = 18 | OPTION-LENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ / AGENT DOMAIN / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Field definition details:

OPTION-CODE:

2 octets; an EDNS0 code that is used in an EDNS0 option to indicate support for error reporting. The name for this EDNS0 option code is Report-Channel.

OPTION-LENGTH:

2 octets; contains the length of the AGENT DOMAIN field in octets.

AGENT DOMAIN:

A fully qualified domain name in uncompressed DNS wire format.

DNS Error Reporting Specification The various errors that a reporting resolver may encounter are listed in . Note that not all listed errors may be supported by the reporting resolver. This document does not specify what is or is not an error. The DNS class is not specified in the error report.

Reporting Resolver Specification Care should be taken when additional DNS resolution is needed to resolve the QNAME that contains the error report. This resolution itself could trigger another error report to be created. A maximum expense or depth limit MUST be used to prevent cascading errors. The EDNS0 Report-Channel option MUST NOT be included in queries. The reporting resolver MUST NOT use DNS error reporting if the authoritative server returned an empty AGENT DOMAIN field in the EDNS0 Report-Channel option. For the monitoring agent to gain more confidence that the report is not spoofed, the reporting resolver SHOULD send error reports over TCP or other connection-oriented protocols or SHOULD use DNS Cookies . This makes it harder to falsify the source address. A reporting resolver MUST validate responses received from the monitoring agent. There is no special treatment for responses to error-reporting queries. ("Security Considerations") contains the rationale behind this.

Constructing the Report Query The QNAME for the report query is constructed by concatenating the following elements:

• A label containing the string "_er".
• The QTYPE that was used in the query that resulted in the extended DNS error, presented as a decimal value, in a single DNS label. If additional QTYPEs were present in the query, such as described in , they are represented as unique, ordered decimal values separated by a hyphen. As an example, if both QTYPE A and AAAA were present in the query, they are presented as the label "1-28".
• The list of non-null labels representing the query name that is the subject of the DNS error report.
• The extended DNS error code, presented as a decimal value, in a single DNS label.
• A label containing the string "_er".
• The agent domain. The agent domain as received in the EDNS0 Report-Channel option set by the authoritative server.

If the QNAME of the report query exceeds 255 octets, it MUST NOT be sent. The "_er" labels allow the monitoring agent to differentiate between the agent domain and the faulty query name. When the specified agent domain is empty, or is a null label (despite being not allowed in this specification), the report query will have "_er" as a top-level domain, and not the top-level domain from the query name that was the subject of this error report. The purpose of the first "_er" label is to indicate that a complete report query has been received instead of a shorter report query due to query minimization.

Authoritative Server Specification The authoritative server MUST NOT include more than one EDNS0 Report-Channel option in a response. The authoritative server includes the EDNS0 Report-Channel option unsolicited in responses. There is no requirement that the EDNS0 Report-Channel option be present in queries.

Monitoring Agent Specification It is RECOMMENDED that the authoritative server for the agent domain reply with a positive response (i.e., not with NODATA or NXDOMAIN) containing a TXT record. The monitoring agent SHOULD respond to queries received over UDP that have no DNS Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to requery over TCP.

IANA Considerations IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)" registry:

Value	Name	Status	Reference
18	Report-Channel	Standard	RFC 9567

IANA has assigned the following in the "Underscored and Globally Scoped DNS Node Names" registry:

RR Type	_NODE NAME	Reference
TXT	_er	RFC 9567

Operational Considerations

Choosing an Agent Domain It is RECOMMENDED that the agent domain be kept relatively short to allow for a longer QNAME in the report query. The agent domain MUST NOT be a subdomain of the domain it is reporting on. That is, if the authoritative server hosts the foo.example domain, then its agent domain MUST NOT end in foo.example.

Managing Caching Optimizations The reporting resolver may utilize various caching optimizations that inhibit subsequent error reporting to the same monitoring agent. If the monitoring agent were to respond with NXDOMAIN (name error), states that any name at or below that domain should be considered unreachable, and negative caching would prohibit subsequent queries for anything at or below that domain for a period of time, depending on the negative TTL . Since the monitoring agent may not know the contents of all the zones for which it acts as a monitoring agent, the monitoring agent MUST NOT respond with NXDOMAIN for domains it is monitoring because that could inhibit subsequent queries. One method to avoid NXDOMAIN is to use a wildcard domain name in the zone for the agent domain. When the agent domain is signed, a resolver may use aggressive negative caching (described in ). This optimization makes use of NSEC and NSEC3 (without opt-out) records and allows the resolver to do the wildcard synthesis. When this happens, the resolver does not send subsequent queries because it will be able to synthesize a response from previously cached material. A solution is to avoid DNSSEC for the agent domain. Signing the agent domain will incur an additional burden on the reporting resolver, as it has to validate the response. However, this response has no utility to the reporting resolver other than dampening the query load for error reports.

Security Considerations Use of DNS error reporting may expose local configuration mistakes in the reporting resolver, such as stale DNSSEC trust anchors, to the monitoring agent. DNS error reporting SHOULD be done using DNS query name minimization to improve privacy. DNS error reporting is done without any authentication between the reporting resolver and the authoritative server of the agent domain. Resolvers that send error reports SHOULD send them over TCP or SHOULD use DNS Cookies . This makes it hard to falsify the source address. The monitoring agent SHOULD respond to queries received over UDP that have no DNS Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to requery over TCP. Well-known addresses of reporting resolvers can provide a higher level of confidence in the error reports and potentially enable more automated processing of these reports. Monitoring agents that receive error reports over UDP should consider that the source of the reports and the reports themselves may be false. The method described in this document will cause additional queries by the reporting resolver to authoritative servers in order to resolve the report query. This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent through open resolvers or widely distributed network monitoring systems that perform distributed queries from around the globe. An adversary may create massive error report flooding to camouflage an attack. Though this document gives no guidance on the content of the RDATA in the TXT resource record, if the RDATA content is logged, the monitoring agent MUST assume the content can be malicious and take appropriate measures to avoid exploitation. One such method could be to log in hexadecimal. This would avoid remote code execution through logging string attacks, such as the vulnerability described in . The rationale behind mandating DNSSEC validation for responses from a reporting agent, even if the agent domain is proposed to remain unsigned, is to mitigate the risk of a downgrade attack orchestrated by adversaries. In such an attack, a victim's legitimately signed domain could be deceptively advertised as an agent domain by malicious actors. Consequently, if the validating resolver treats it as unsigned, it is exposed to potential cache poisoning attacks. By enforcing DNSSEC validation, this vulnerability is preemptively addressed.

References Normative References 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. Informative References CVE Internet Systems Consortium, Inc. This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. Work in Progress RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. 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. This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. 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.

Acknowledgements This document is based on an idea by and . The authors would like to thank , , , , , , , , , , , , , , , , , , , , , , and for their contributions.

Authors' Addresses ICANN

roy.arends@icann.org

ICANN

matt.larson@icann.org