1 Internet Engineering Task Force (IETF) R. Arends
2 Request for Comments: 9567 M. Larson
3 Category: Standards Track ICANN
4 ISSN: 2070-1721 April 2024
5
6
7 DNS Error Reporting
8
9 Abstract
10
11 DNS error reporting is a lightweight reporting mechanism that
12 provides the operator of an authoritative server with reports on DNS
13 resource records that fail to resolve or validate. A domain owner or
14 DNS hosting organization can use these reports to improve domain
15 hosting. The reports are based on extended DNS errors as described
16 in RFC 8914.
17
18 When a domain name fails to resolve or validate due to a
19 misconfiguration or an attack, the operator of the authoritative
20 server may be unaware of this. To mitigate this lack of feedback,
21 this document describes a method for a validating resolver to
22 automatically signal an error to a monitoring agent specified by the
23 authoritative server. The error is encoded in the QNAME; thus, the
24 very act of sending the query is to report the error.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 7841.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 https://www.rfc-editor.org/info/rfc9567.
39
40 Copyright Notice
41
42 Copyright (c) 2024 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
44
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Revised BSD License text as described in Section 4.e of the
52 Trust Legal Provisions and are provided without warranty as described
53 in the Revised BSD License.
54
55 Table of Contents
56
57 1. Introduction
58 2. Requirements Notation
59 3. Terminology
60 4. Overview
61 4.1. Example
62 5. EDNS0 Option Specification
63 6. DNS Error Reporting Specification
64 6.1. Reporting Resolver Specification
65 6.1.1. Constructing the Report Query
66 6.2. Authoritative Server Specification
67 6.3. Monitoring Agent Specification
68 7. IANA Considerations
69 8. Operational Considerations
70 8.1. Choosing an Agent Domain
71 8.2. Managing Caching Optimizations
72 9. Security Considerations
73 10. References
74 10.1. Normative References
75 10.2. Informative References
76 Acknowledgements
77 Authors' Addresses
78
79 1. Introduction
80
81 When an authoritative server serves a stale DNSSEC-signed zone, the
82 cryptographic signatures over the resource record sets (RRsets) may
83 have lapsed. A validating resolver will fail to validate these
84 resource records.
85
86 Similarly, when there is a mismatch between the Delegation Signer
87 (DS) records at a parent zone and the key signing key at the child
88 zone, a validating resolver will fail to authenticate records in the
89 child zone.
90
91 These are two of several failure scenarios that may go unnoticed for
92 some time by the operator of a zone.
93
94 Today, there is no direct relationship between operators of
95 validating resolvers and authoritative servers. Outages are often
96 noticed indirectly by end users and reported via email or social
97 media (if reported at all).
98
99 When records fail to validate, there is no facility to report this
100 failure in an automated way. If there is any indication that an
101 error or warning has happened, it may be buried in log files of the
102 resolver or not logged at all.
103
104 This document describes a method that can be used by validating
105 resolvers to report DNSSEC validation errors in an automated way.
106
107 It allows an authoritative server to announce a monitoring agent to
108 which validating resolvers can report issues if those resolvers are
109 configured to do so.
110
111 The burden to report a failure falls on the validating resolver. It
112 is important that the effort needed to report failure is low, with
113 minimal impact to its main functions. To accomplish this goal, the
114 DNS itself is utilized to report the error.
115
116 2. Requirements Notation
117
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
120 "OPTIONAL" in this document are to be interpreted as described in
121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
122 capitals, as shown here.
123
124 3. Terminology
125
126 This document uses DNS terminology defined in BCP 219 [RFC9499].
127 This document also defines and uses the following terms:
128
129 Reporting resolver: A validating resolver that supports DNS error
130 reporting.
131
132 Report query: The DNS query used to report an error. A report query
133 is for a DNS TXT resource record type. The content of the error
134 report is encoded in the QNAME of a DNS request to the monitoring
135 agent.
136
137 Monitoring agent: An authoritative server that receives and responds
138 to report queries. This facility is indicated by a domain name,
139 referred to as the "agent domain".
140
141 Agent domain: A domain name that is returned in the EDNS0 Report-
142 Channel option and indicates where DNS resolvers can send error
143 reports.
144
145 4. Overview
146
147 An authoritative server indicates support for DNS error reporting by
148 including an EDNS0 Report-Channel option with OPTION-CODE 18 and the
149 agent domain in the response. The agent domain is a fully qualified,
150 uncompressed domain name in DNS wire format. The authoritative
151 server MUST NOT include this option in the response if the configured
152 agent domain is empty or is the null label (which would indicate the
153 DNS root).
154
155 The authoritative server includes the EDNS0 Report-Channel option
156 unsolicited. That is, the option is included in a response despite
157 the EDNS0 Report-Channel option being absent in the request.
158
159 If the authoritative server has indicated support for DNS error
160 reporting and there is an issue that can be reported via extended DNS
161 errors, the reporting resolver encodes the error report in the QNAME
162 of the report query. The reporting resolver builds this QNAME by
163 concatenating the "_er" label, the QTYPE, the QNAME that resulted in
164 failure, the extended DNS error code (as described in [RFC8914]), the
165 label "_er" again, and the agent domain. See the example in
166 Section 4.1 and the specification in Section 6.1.1. Note that a
167 regular RCODE is not included because the RCODE is not relevant to
168 the extended DNS error code.
169
170 The resulting report query is sent as a standard DNS query for a TXT
171 DNS resource record type by the reporting resolver.
172
173 The report query will ultimately arrive at the monitoring agent. A
174 response is returned by the monitoring agent, which in turn can be
175 cached by the reporting resolver. This caching is essential. It
176 dampens the number of report queries sent by a reporting resolver for
177 the same problem (that is, with caching, one report query per TTL is
178 sent). However, certain optimizations, such as those described in
179 [RFC8020] and [RFC8198], may reduce the number of error report
180 queries as well.
181
182 This document gives no guidance on the content of the RDATA in the
183 TXT resource record.
184
185 4.1. Example
186
187 A query for "broken.test.", type A, is sent by a reporting resolver.
188
189 The domain "test." is hosted on a set of authoritative servers. One
190 of these authoritative servers serves a stale version of the "test."
191 zone. This authoritative server has an agent domain configured as
192 "a01.agent-domain.example.".
193
194 The authoritative server with the stale "test." zone receives the
195 request for "broken.test.". It returns a response that includes the
196 EDNS0 Report-Channel option with the domain name "a01.agent-
197 domain.example.".
198
199 The reporting resolver is unable to validate the "broken.test."
200 RRset for type A (an RR type with value 1), due to an RRSIG record
201 with an expired signature.
202
203 The reporting resolver constructs the QNAME
204 "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it.
205 This QNAME indicates extended DNS error 7 occurred while trying to
206 validate "broken.test." for a type A (an RR type with value 1)
207 record.
208
209 When this query is received at the monitoring agent (the operators of
210 the authoritative server for "a01.agent-domain.example."), the agent
211 can determine the "test." zone contained an expired signature record
212 (extended DNS error 7) for type A for the domain name "broken.test.".
213 The monitoring agent can contact the operators of "test." to fix the
214 issue.
215
216 5. EDNS0 Option Specification
217
218 This method uses an EDNS0 [RFC6891] option to indicate the agent
219 domain in DNS responses. The option is structured as follows:
220
221 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
222 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
223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224 | OPTION-CODE = 18 | OPTION-LENGTH |
225 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
226 / AGENT DOMAIN /
227 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
228
229 Field definition details:
230
231 OPTION-CODE: 2 octets; an EDNS0 code that is used in an EDNS0 option
232 to indicate support for error reporting. The name for this EDNS0
233 option code is Report-Channel.
234
235 OPTION-LENGTH: 2 octets; contains the length of the AGENT DOMAIN
236 field in octets.
237
238 AGENT DOMAIN: A fully qualified domain name [RFC9499] in
239 uncompressed DNS wire format.
240
241 6. DNS Error Reporting Specification
242
243 The various errors that a reporting resolver may encounter are listed
244 in [RFC8914]. Note that not all listed errors may be supported by
245 the reporting resolver. This document does not specify what is or is
246 not an error.
247
248 The DNS class is not specified in the error report.
249
250 6.1. Reporting Resolver Specification
251
252 Care should be taken when additional DNS resolution is needed to
253 resolve the QNAME that contains the error report. This resolution
254 itself could trigger another error report to be created. A maximum
255 expense or depth limit MUST be used to prevent cascading errors.
256
257 The EDNS0 Report-Channel option MUST NOT be included in queries.
258
259 The reporting resolver MUST NOT use DNS error reporting if the
260 authoritative server returned an empty AGENT DOMAIN field in the
261 EDNS0 Report-Channel option.
262
263 For the monitoring agent to gain more confidence that the report is
264 not spoofed, the reporting resolver SHOULD send error reports over
265 TCP [RFC7766] or other connection-oriented protocols or SHOULD use
266 DNS Cookies [RFC7873]. This makes it harder to falsify the source
267 address.
268
269 A reporting resolver MUST validate responses received from the
270 monitoring agent. There is no special treatment for responses to
271 error-reporting queries. Section 9 ("Security Considerations")
272 contains the rationale behind this.
273
274 6.1.1. Constructing the Report Query
275
276 The QNAME for the report query is constructed by concatenating the
277 following elements:
278
279 * A label containing the string "_er".
280
281 * The QTYPE that was used in the query that resulted in the extended
282 DNS error, presented as a decimal value, in a single DNS label.
283 If additional QTYPEs were present in the query, such as described
284 in [MULTI-QTYPES], they are represented as unique, ordered decimal
285 values separated by a hyphen. As an example, if both QTYPE A and
286 AAAA were present in the query, they are presented as the label
287 "1-28".
288
289 * The list of non-null labels representing the query name that is
290 the subject of the DNS error report.
291
292 * The extended DNS error code, presented as a decimal value, in a
293 single DNS label.
294
295 * A label containing the string "_er".
296
297 * The agent domain. The agent domain as received in the EDNS0
298 Report-Channel option set by the authoritative server.
299
300 If the QNAME of the report query exceeds 255 octets, it MUST NOT be
301 sent.
302
303 The "_er" labels allow the monitoring agent to differentiate between
304 the agent domain and the faulty query name. When the specified agent
305 domain is empty, or is a null label (despite being not allowed in
306 this specification), the report query will have "_er" as a top-level
307 domain, and not the top-level domain from the query name that was the
308 subject of this error report. The purpose of the first "_er" label
309 is to indicate that a complete report query has been received instead
310 of a shorter report query due to query minimization.
311
312 6.2. Authoritative Server Specification
313
314 The authoritative server MUST NOT include more than one EDNS0 Report-
315 Channel option in a response.
316
317 The authoritative server includes the EDNS0 Report-Channel option
318 unsolicited in responses. There is no requirement that the EDNS0
319 Report-Channel option be present in queries.
320
321 6.3. Monitoring Agent Specification
322
323 It is RECOMMENDED that the authoritative server for the agent domain
324 reply with a positive response (i.e., not with NODATA or NXDOMAIN)
325 containing a TXT record.
326
327 The monitoring agent SHOULD respond to queries received over UDP that
328 have no DNS Cookie set with a response that has the truncation bit
329 (TC bit) set to challenge the resolver to requery over TCP.
330
331 7. IANA Considerations
332
333 IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)"
334 registry:
335
336 +=======+================+==========+===========+
337 | Value | Name | Status | Reference |
338 +=======+================+==========+===========+
339 | 18 | Report-Channel | Standard | RFC 9567 |
340 +-------+----------------+----------+-----------+
341
342 Table 1
343
344 IANA has assigned the following in the "Underscored and Globally
345 Scoped DNS Node Names" registry:
346
347 +=========+============+===========+
348 | RR Type | _NODE NAME | Reference |
349 +=========+============+===========+
350 | TXT | _er | RFC 9567 |
351 +---------+------------+-----------+
352
353 Table 2
354
355 8. Operational Considerations
356
357 8.1. Choosing an Agent Domain
358
359 It is RECOMMENDED that the agent domain be kept relatively short to
360 allow for a longer QNAME in the report query. The agent domain MUST
361 NOT be a subdomain of the domain it is reporting on. That is, if the
362 authoritative server hosts the foo.example domain, then its agent
363 domain MUST NOT end in foo.example.
364
365 8.2. Managing Caching Optimizations
366
367 The reporting resolver may utilize various caching optimizations that
368 inhibit subsequent error reporting to the same monitoring agent.
369
370 If the monitoring agent were to respond with NXDOMAIN (name error),
371 [RFC8020] states that any name at or below that domain should be
372 considered unreachable, and negative caching would prohibit
373 subsequent queries for anything at or below that domain for a period
374 of time, depending on the negative TTL [RFC2308].
375
376 Since the monitoring agent may not know the contents of all the zones
377 for which it acts as a monitoring agent, the monitoring agent MUST
378 NOT respond with NXDOMAIN for domains it is monitoring because that
379 could inhibit subsequent queries. One method to avoid NXDOMAIN is to
380 use a wildcard domain name [RFC4592] in the zone for the agent
381 domain.
382
383 When the agent domain is signed, a resolver may use aggressive
384 negative caching (described in [RFC8198]). This optimization makes
385 use of NSEC and NSEC3 (without opt-out) records and allows the
386 resolver to do the wildcard synthesis. When this happens, the
387 resolver does not send subsequent queries because it will be able to
388 synthesize a response from previously cached material.
389
390 A solution is to avoid DNSSEC for the agent domain. Signing the
391 agent domain will incur an additional burden on the reporting
392 resolver, as it has to validate the response. However, this response
393 has no utility to the reporting resolver other than dampening the
394 query load for error reports.
395
396 9. Security Considerations
397
398 Use of DNS error reporting may expose local configuration mistakes in
399 the reporting resolver, such as stale DNSSEC trust anchors, to the
400 monitoring agent.
401
402 DNS error reporting SHOULD be done using DNS query name minimization
403 [RFC9156] to improve privacy.
404
405 DNS error reporting is done without any authentication between the
406 reporting resolver and the authoritative server of the agent domain.
407
408 Resolvers that send error reports SHOULD send them over TCP [RFC7766]
409 or SHOULD use DNS Cookies [RFC7873]. This makes it hard to falsify
410 the source address. The monitoring agent SHOULD respond to queries
411 received over UDP that have no DNS Cookie set with a response that
412 has the truncation bit (TC bit) set to challenge the resolver to
413 requery over TCP.
414
415 Well-known addresses of reporting resolvers can provide a higher
416 level of confidence in the error reports and potentially enable more
417 automated processing of these reports.
418
419 Monitoring agents that receive error reports over UDP should consider
420 that the source of the reports and the reports themselves may be
421 false.
422
423 The method described in this document will cause additional queries
424 by the reporting resolver to authoritative servers in order to
425 resolve the report query.
426
427 This method can be abused by intentionally deploying broken zones
428 with agent domains that are delegated to victims. This is
429 particularly effective when DNS requests that trigger error messages
430 are sent through open resolvers [RFC9499] or widely distributed
431 network monitoring systems that perform distributed queries from
432 around the globe.
433
434 An adversary may create massive error report flooding to camouflage
435 an attack.
436
437 Though this document gives no guidance on the content of the RDATA in
438 the TXT resource record, if the RDATA content is logged, the
439 monitoring agent MUST assume the content can be malicious and take
440 appropriate measures to avoid exploitation. One such method could be
441 to log in hexadecimal. This would avoid remote code execution
442 through logging string attacks, such as the vulnerability described
443 in [CVE-2021-44228].
444
445 The rationale behind mandating DNSSEC validation for responses from a
446 reporting agent, even if the agent domain is proposed to remain
447 unsigned, is to mitigate the risk of a downgrade attack orchestrated
448 by adversaries. In such an attack, a victim's legitimately signed
449 domain could be deceptively advertised as an agent domain by
450 malicious actors. Consequently, if the validating resolver treats it
451 as unsigned, it is exposed to potential cache poisoning attacks. By
452 enforcing DNSSEC validation, this vulnerability is preemptively
453 addressed.
454
455 10. References
456
457 10.1. Normative References
458
459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
460 Requirement Levels", BCP 14, RFC 2119,
461 DOI 10.17487/RFC2119, March 1997,
462 <https://www.rfc-editor.org/info/rfc2119>.
463
464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
466 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
467
468 10.2. Informative References
469
470 [CVE-2021-44228]
471 CVE, "CVE-2021-44228", 26 November 2021,
472 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
473 2021-44228>.
474
475 [MULTI-QTYPES]
476 Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
477 Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4
478 December 2023, <https://datatracker.ietf.org/doc/html/
479 draft-ietf-dnssd-multi-qtypes-00>.
480
481 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
482 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
483 <https://www.rfc-editor.org/info/rfc2308>.
484
485 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
486 System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
487 <https://www.rfc-editor.org/info/rfc4592>.
488
489 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
490 for DNS (EDNS(0))", STD 75, RFC 6891,
491 DOI 10.17487/RFC6891, April 2013,
492 <https://www.rfc-editor.org/info/rfc6891>.
493
494 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
495 D. Wessels, "DNS Transport over TCP - Implementation
496 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
497 <https://www.rfc-editor.org/info/rfc7766>.
498
499 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
500 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
501 <https://www.rfc-editor.org/info/rfc7873>.
502
503 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
504 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
505 November 2016, <https://www.rfc-editor.org/info/rfc8020>.
506
507 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
508 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
509 July 2017, <https://www.rfc-editor.org/info/rfc8198>.
510
511 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
512 Lawrence, "Extended DNS Errors", RFC 8914,
513 DOI 10.17487/RFC8914, October 2020,
514 <https://www.rfc-editor.org/info/rfc8914>.
515
516 [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
517 Name Minimisation to Improve Privacy", RFC 9156,
518 DOI 10.17487/RFC9156, November 2021,
519 <https://www.rfc-editor.org/info/rfc9156>.
520
521 [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
522 RFC 9499, DOI 10.17487/RFC9499, March 2024,
523 <https://www.rfc-editor.org/info/rfc9499>.
524
525 Acknowledgements
526
527 This document is based on an idea by Roy Arends and David Conrad.
528 The authors would like to thank Peter van Dijk, Stephane Bortzmeyer,
529 Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark
530 Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay,
531 Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes
532 Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst,
533 Benno Overeinder, Paul Wouters, and Petr Spacek for their
534 contributions.
535
536 Authors' Addresses
537
538 Roy Arends
539 ICANN
540 Email: roy.arends@icann.org
541
542
543 Matt Larson
544 ICANN
545 Email: matt.larson@icann.org
546
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.