DNS Error Reporting

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 5 September 2024.¶

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 (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. 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 E-Mail 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 where 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

DNS Terminology used in this document is from BCP 219 [RFC8499], with these additions:¶

Reporting resolver:

In the context of this document, "reporting resolver" is used as a shorthand for a validating resolver that supports DNS error reporting.¶

Report query:

The DNS query used to report an error is called a report query. 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 which is returned in the DNS Error Reporting EDNS0 option that indicates where DNS resolvers can send error reports.¶

4. Overview

An authoritative server indicates support for DNS error reporting by including an EDNS0 Report-Channel option with OPTION-CODE [TBD] 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 error code (as described in [RFC8914]), the label "_er" again, and the agent domain. See the example in Section 4.1. Note that a regular RCODE is not included because the RCODE is not relevant to the extended 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, once per TTL. However, certain optimizations such as [RFC8020] and [RFC8198] may reduce the number of error report queries as well.¶

This document gives no guidance on the content of the TXT resource record RDATA for this record.¶

5. EDNS0 Option Specification

This method uses an EDNS0 [RFC6891] 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 = TBD      |       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 [RFC8499] in uncompressed DNS wire format.¶

6. DNS error reporting specification

The various errors that a reporting resolver may encounter are listed in [RFC8914]. 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.¶

7. IANA Considerations

IANA is requested to assign the following DNS EDNS0 option code registry:¶

      Value Name           Status   Reference
      ----- -------------- -------- ---------------
      TBD   Report-Channel Standard [this document]

IANA is requested to assign the following Underscored and Globally Scoped DNS Node Name registry:¶

      RR Type  _NODE NAME  Reference
      -----    ----------  ---------
      TXT      _er         [this document]

8. Operational Considerations

9. 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 [RFC9156] 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 these over TCP [RFC7766] or SHOULD use DNS COOKIEs [RFC7873]. 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 re-query 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 itself 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 [RFC8499] 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 TXT resource record RDATA for this record, if the RDATA content is logged, it MUST assume the content can be malicious and take appropriate meassures to avoid exploitation. One such method could be to log in hexadecimal. This would avoid remote code execution through logging string attacks such as [CVE-2021-44228].¶

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

10. Acknowledgements

This document is based on an idea by Roy Arends and David Conrad. The authors would like to thank Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst, Benno Overeinder, Paul Wouters and Petr Spacek for their contributions.¶

Authors' Addresses