RFC 9567

DNS Error Reporting

📅 published April 2024, from ietf

RFC 9567: DNS Error Reporting 🎀

Okay bestie, let's get into this one. RFC 9567 is called DNS Error Reporting, and it came out of the IETF in April 2024 ✨. The authors are R. Arends and M. Larson, both at ICANN 💅. It's a Standards Track doc (so it's an actual Internet standard, not just an idea), and its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, since there are no Obsoletes or Updates lines in its header 🧚.

Abstract 💜

So DNS error reporting is a lightweight reporting mechanism that gives the operator of an authoritative server reports on DNS resource records that fail to resolve or validate 😭. A domain owner or DNS hosting organization can use those reports to improve their domain hosting 🫶. The reports are built on extended DNS errors from RFC 8914.

When a domain name fails to resolve or validate because of a misconfiguration or an attack, the authoritative server operator might not even know 🙈. So this document describes a way for a validating resolver to automatically signal an error to a monitoring agent that the authoritative server has named. The error gets encoded in the QNAME, which means the very act of sending the query is the report. Iconic, honestly 👑.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🌸.

For the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9567 🦋.

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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 💖.

Table of Contents 🗂️

   1.  Introduction
   2.  Requirements Notation
   3.  Terminology
   4.  Overview
     4.1.  Example
   5.  EDNS0 Option Specification
   6.  DNS Error Reporting Specification
     6.1.  Reporting Resolver Specification
       6.1.1.  Constructing the Report Query
     6.2.  Authoritative Server Specification
     6.3.  Monitoring Agent Specification
   7.  IANA Considerations
   8.  Operational Considerations
     8.1.  Choosing an Agent Domain
     8.2.  Managing Caching Optimizations
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

Okay so, when an authoritative server serves a stale DNSSEC-signed zone, the signatures over the resource record sets (RRsets) might have expired 😬. A validating resolver then can't validate those records. Lowkey a disaster.

It's the same deal when the Delegation Signer (DS) records at the parent zone don't match the key signing key at the child zone. The validating resolver fails to authenticate the records in the child zone 💀.

Those are only two of several failure scenarios that can go unnoticed for a while by the zone's operator 🙈.

Right now there's no direct relationship between validating resolver operators and authoritative server operators. Outages usually get noticed indirectly by end users, who report them over email or social media (if they report them at all) 😭.

Also, when records fail to validate, there's no automated way to report it. If there's any sign that an error or warning happened, it might be buried in the resolver's log files, or it might not get logged at all 🫠.

So this document describes a method validating resolvers can use to report DNSSEC validation errors automatically 🔥. It lets an authoritative server announce a monitoring agent that validating resolvers can report issues to, as long as those resolvers are configured to do that 🧚.

The burden of reporting a failure falls on the validating resolver. It's important that reporting is low-effort and has minimal impact on the resolver's main jobs, so the DNS itself gets used to do the reporting 💅.

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 📚

This document uses DNS terminology defined in BCP 219 [RFC9499]. It 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 gets encoded in the QNAME of a DNS request sent to the monitoring agent.
  • Monitoring agent: An authoritative server that receives and responds to report queries. This facility is pointed to by a domain name, referred to as the "agent domain".
  • Agent domain: A domain name that's returned in the EDNS0 Report-Channel option and tells DNS resolvers where they can send error reports.

4. Overview 🌈

An authoritative server says it supports DNS error reporting by putting an EDNS0 Report-Channel option with OPTION-CODE 18, plus 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 mean the DNS root) 🙅‍♀️.

The authoritative server includes the EDNS0 Report-Channel option unsolicited. That means it shows up in the response even though the request didn't include the EDNS0 Report-Channel option 🌸.

If the authoritative server has indicated support for DNS error reporting, and there's an issue that can be reported through extended DNS errors, the reporting resolver encodes the error report in the QNAME of the report query. It builds the QNAME by concatenating the "_er" label, the QTYPE, the QNAME that caused the failure, the extended DNS error code (from [RFC8914]), the label "_er" again, and then the agent domain 🧩. Check out Section 4.1 for an example and Section 6.1.1 for the actual spec. Also, a regular RCODE isn't included, because the RCODE doesn't matter for the extended DNS error code 🙈.

The resulting report query gets sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver 🫶.

The report query eventually arrives at the monitoring agent, which sends back a response. The reporting resolver can cache that response, and the caching is essential ✨. It dampens the number of report queries a reporting resolver sends for the same problem. With caching, only one report query gets sent per TTL 🔥. Certain optimizations, like the ones in [RFC8020] and [RFC8198], may cut down on the number of error report queries too 💅.

This document gives no guidance on the content of the RDATA in the TXT resource record 🤷‍♀️.

4.1. Example 🔍

A reporting resolver sends a query for "broken.test.", type A 📨.

The domain "test." is hosted on a set of authoritative servers. One of those servers is serving a stale version of the "test." zone. That authoritative server has an agent domain configured as "a01.agent-domain.example." 🍓.

The authoritative server with the stale "test." zone gets 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 can't validate the "broken.test." RRset for type A (an RR type with value 1), because there's an RRSIG record with an expired signature 😭.

So the reporting resolver builds the QNAME _er.1.broken.test.7._er.a01.agent-domain.example. and resolves it 🧚. This QNAME says extended DNS error 7 happened while trying to validate "broken.test." for a type A (an RR type with value 1) record 💜.

When this query reaches the monitoring agent (the operators of the authoritative server for "a01.agent-domain.example."), the agent can figure out that the "test." zone had an expired signature record (extended DNS error 7) for type A on the domain name "broken.test." 🕵️‍♀️. Then the monitoring agent can contact the operators of "test." to get it fixed 🔧.

5. EDNS0 Option Specification 🧾

This method uses an EDNS0 [RFC6891] option to indicate the agent domain in DNS responses. The option is structured like this 🖼️:

                        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                          /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Here's the field breakdown 🍰:

  • OPTION-CODE: 2 octets. It's an EDNS0 code 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. It holds the length of the AGENT DOMAIN field, in octets.
  • AGENT DOMAIN: A fully qualified domain name [RFC9499] in uncompressed DNS wire format.

6. DNS Error Reporting Specification 🛠️

The various errors a reporting resolver might run into are listed in [RFC8914]. Heads up: not every listed error has to be supported by the reporting resolver. This document doesn't say what is or isn't an error 🤓.

The DNS class isn't specified in the error report 💅.

6.1. Reporting Resolver Specification 🧠

Care should be taken when extra DNS resolution is needed to resolve the QNAME that holds the error report. That resolution could trigger yet another error report, so it's a bit of a loop risk 🌀. A maximum expense or depth limit MUST be used to stop 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 🚫.

To help the monitoring agent feel more confident that a report isn't spoofed, the reporting resolver SHOULD send error reports over TCP [RFC7766] or another connection-oriented protocol, or SHOULD use DNS Cookies [RFC7873]. This makes it harder to fake the source address 🔐.

A reporting resolver MUST validate responses received from the monitoring agent. There's no special treatment for responses to error-reporting queries, and Section 9 ("Security Considerations") explains the reasoning behind this 🫢.

6.1.1. Constructing the Report Query

okay so the QNAME for the report query gets built by stacking these pieces together, in this order 💅

  • A label containing the string _er.
  • The QTYPE that was used in the query that caused the extended DNS error, written as a decimal value in a single DNS label. If extra QTYPEs were in the query, like in [MULTI-QTYPES], they go in as unique, ordered decimal values separated by a hyphen. For example, if both QTYPE A and AAAA were there, you get the label "1-28" 🦋
  • The list of non-null labels for the query name that's the subject of the DNS error report.
  • The extended DNS error code, written as a decimal value in a single DNS label.
  • A label containing the string _er.
  • The agent domain, exactly as the authoritative server put it in the EDNS0 Report-Channel option.

If the QNAME of the report query goes over 255 octets, it MUST NOT be sent. no exceptions, bestie 🙅‍♀️

The _er labels are doing a lot of work here 🧚. They let the monitoring agent tell the agent domain apart from the faulty query name. If the agent domain is empty, or is a null label (even though this spec says that's not allowed), the report query ends up with _er as its top-level domain, not the TLD from the query name that got reported. The first _er label is also how the agent knows it's looking at a complete report query and not a shorter one that got cut down by query minimization. iconic design, honestly 😭

6.2. Authoritative Server Specification

The authoritative server MUST NOT include more than one EDNS0 Report-Channel option in a response. one is the limit, periodt 💅

The authoritative server adds the EDNS0 Report-Channel option unsolicited in its responses. There's no requirement that the EDNS0 Report-Channel option show up in queries 🌸

6.3. 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. a positive answer with a TXT record is the vibe 🎀

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. this challenges the resolver to requery over TCP. it's giving bouncer energy, lowkey iconic 🔥

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

                               Table 1

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

                +=========+============+===========+
                | RR Type | _NODE NAME | Reference |
                +=========+============+===========+
                | TXT     | _er        | RFC 9567  |
                +---------+------------+-----------+

                              Table 2

8. Operational Considerations 🍓

8.1. Choosing an Agent Domain

It is RECOMMENDED that the agent domain be kept relatively short so there's room for a longer QNAME in the report query. ngl, short and sweet is the move ✨ The agent domain MUST NOT be a subdomain of the domain it's reporting on. So if the authoritative server hosts the foo.example domain, its agent domain MUST NOT end in foo.example. not me making that mistake 🙈

8.2. Managing Caching Optimizations

The reporting resolver might use various caching optimizations that get in the way of later error reporting to the same monitoring agent. it's a whole thing 💀

If the monitoring agent were to respond with NXDOMAIN (name error), [RFC8020] says that any name at or below that domain should be considered unreachable. Negative caching would then stop subsequent queries for anything at or below that domain for a while, depending on the negative TTL [RFC2308]. yikes, the cache really holds a grudge 😭

Since the monitoring agent might not know the contents of all the zones it's monitoring for, the monitoring agent MUST NOT respond with NXDOMAIN for domains it is monitoring, because that could block later queries. One way to avoid NXDOMAIN is to use a wildcard domain name [RFC4592] in the zone for the agent domain 🌈

When the agent domain is signed, a resolver may use aggressive negative caching (described in [RFC8198]). This optimization uses NSEC and NSEC3 records (without opt-out) and lets the resolver do the wildcard synthesis. When that happens, the resolver doesn't send subsequent queries, because it can synthesize a response from material it already cached. galaxy-brain move, respect 🧠✨

Another option is to skip DNSSEC for the agent domain. Signing the agent domain adds an extra burden on the reporting resolver, since it has to validate the response. But that response has no use to the reporting resolver other than cutting down the query load for error reports 💅

9. Security Considerations 🔥

Using DNS error reporting might expose local configuration mistakes in the reporting resolver, like stale DNSSEC trust anchors, to the monitoring agent. oversharing alert 🙈

DNS error reporting SHOULD be done using DNS query name minimization [RFC9156] to help with privacy. protect your bestie's privacy 🫶

DNS error reporting is done without any authentication between the reporting resolver and the authoritative server of the agent domain. no auth, so be careful out there 😬

Resolvers that send error reports SHOULD send them over TCP [RFC7766] or SHOULD use DNS Cookies [RFC7873]. This makes it hard to fake 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 give a higher level of confidence in the error reports, and could potentially enable more automated processing of those reports 🦋

Monitoring agents that receive error reports over UDP should consider that the source of the reports, and the reports themselves, may be false. trust but verify, babe 👀

The method in this document causes additional queries from the reporting resolver to authoritative servers, so it can resolve the report query. extra traffic, noted 📈

This method can be abused by deliberately deploying broken zones whose agent domains are delegated to victims. It's especially effective when the DNS requests that trigger error messages go through open resolvers [RFC9499], or through widely distributed network monitoring systems that run distributed queries from all around the globe 🌍💀

An adversary might create a massive flood of error reports to hide an attack. chaotic villain arc 😈

This document gives no guidance on the content of the RDATA in the TXT resource record. Still, if the RDATA content gets logged, the monitoring agent MUST assume the content can be malicious and take appropriate measures to avoid exploitation. One such measure could be logging in hexadecimal. That avoids remote code execution through logging string attacks, like the vulnerability described in [CVE-2021-44228]. this part is seriously important, so log responsibly 🚨

The reason for requiring DNSSEC validation for responses from a reporting agent, even when the agent domain is proposed to stay unsigned, is to reduce the risk of a downgrade attack set up by adversaries. In that attack, a victim's legitimately signed domain could be deceptively advertised as an agent domain by malicious actors. So if the validating resolver treats it as unsigned, it's exposed to potential cache poisoning attacks. By enforcing DNSSEC validation, this vulnerability gets preemptively addressed 🛡️👑

10. References 📚

10.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[CVE-2021-44228]
           CVE, "CVE-2021-44228", 26 November 2021,
           <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
           2021-44228>.

[MULTI-QTYPES]
           Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
           Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4
           December 2023, <https://datatracker.ietf.org/doc/html/
           draft-ietf-dnssd-multi-qtypes-00>.

[RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
           NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
           <https://www.rfc-editor.org/info/rfc2308>.

[RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
           System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
           <https://www.rfc-editor.org/info/rfc4592>.

[RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
           for DNS (EDNS(0))", STD 75, RFC 6891,
           DOI 10.17487/RFC6891, April 2013,
           <https://www.rfc-editor.org/info/rfc6891>.

[RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
           D. Wessels, "DNS Transport over TCP - Implementation
           Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
           <https://www.rfc-editor.org/info/rfc7766>.

[RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
           Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
           <https://www.rfc-editor.org/info/rfc7873>.

[RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
           Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
           November 2016, <https://www.rfc-editor.org/info/rfc8020>.

[RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
           DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
           July 2017, <https://www.rfc-editor.org/info/rfc8198>.

[RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
           Lawrence, "Extended DNS Errors", RFC 8914,
           DOI 10.17487/RFC8914, October 2020,
           <https://www.rfc-editor.org/info/rfc8914>.

[RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
           Name Minimisation to Improve Privacy", RFC 9156,
           DOI 10.17487/RFC9156, November 2021,
           <https://www.rfc-editor.org/info/rfc9156>.

[RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
           RFC 9499, DOI 10.17487/RFC9499, March 2024,
           <https://www.rfc-editor.org/info/rfc9499>.

Acknowledgements 🫶

this doc is based on an idea from Roy Arends and David Conrad 🎀 the authors also want 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 🦋

Roy Arends ICANN Email: roy.arends@icann.org

Matt Larson ICANN Email: matt.larson@icann.org

📦 where this page comes from