idnits 2.17.1 draft-ietf-dnsop-dns-error-reporting-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8914]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 09, 2021) is 898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 165, but not defined -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop R. Arends 3 Internet-Draft M. Larson 4 Intended status: Standards Track ICANN 5 Expires: May 13, 2022 November 09, 2021 7 DNS Error Reporting 8 draft-ietf-dnsop-dns-error-reporting-01 10 Abstract 12 DNS Error Reporting is a lightweight error reporting mechanism that 13 provides the operator of an authoritative server with reports on DNS 14 resource records that fail to resolve or validate, that a Domain 15 Owner or DNS Hosting organization can use to improve domain hosting. 16 The reports are based on Extended DNS Errors [RFC8914]. 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 recursive resolver 22 to automatically signal an error to an agent specified by the 23 authoritative server. DNS Error Reporting uses the DNS to report 24 errors. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 13, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Managing Caching Optimizations . . . . . . . . . . . . . 4 65 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. EDNS0 Option Specification . . . . . . . . . . . . . . . . . 6 67 6. DNS Error Reporting Specification . . . . . . . . . . . . . . 6 68 6.1. Reporting Resolver Specification . . . . . . . . . . . . 7 69 6.1.1. Constructing the Reporting Query . . . . . . . . . . 7 70 6.2. Authoritative Server Specification . . . . . . . . . . . 8 71 6.3. Reporting Agent Specification . . . . . . . . . . . . . . 8 72 6.4. Choosing a Reporting Agent Domain . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 10. Informative References . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 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 recursive resolver will fail to validate 84 these resource records. 86 Similarly, when there is a mismatch between the DS records at a 87 parent zone and the key signing key at the child zone, a validating 88 recursive resolver will fail to authenticate records in the child 89 zone. 91 These are two of several failure scenarios that may go unnoticed for 92 some time by the operator of a zone. 94 There is no direct relationship between operators of validating 95 recursive resolvers and authoritative servers. Outages are often 96 noticed indirectly, by end users, and reported via social media, if 97 reported at all. 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 is buried in log files of the 102 validating resolver, if these errors are logged at all. 104 This document describes a facility that can be used by validating 105 recursive resolvers to report errors in an automated way. 107 It allows an authoritative server to signal a reporting agent where 108 the validating recursive resolver can report issues if it is 109 configured to do so. 111 The burden of reporting a failure falls on the validating recursive 112 resolver. It is important that the effort needed to report failure 113 is low, with minimal impact to its main functions. To accomplish 114 this goal, the DNS itself is utilized to report the error. 116 2. Requirements Notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Terminology 124 Reporting Resolver: In the context of this document, the term 125 reporting resolver is used as a shorthand for a validating recursive 126 resolver that supports DNS Error Reporting. 128 Reporting Query: The DNS query used to report an error is called a 129 reporting query. A reporting query is for DNS resource record type 130 NULL. The details of the error report are encoded in the QNAME of 131 the reporting query. 133 Reporting Agent: A facility responsible for receiving error reports 134 on behalf of authoritative servers. This facility is indicated by a 135 domain name. 137 Reporting Agent Domain: a domain name which the reporting resolver 138 includes in the QNAME of the reporting query. 140 4. Overview 142 An authoritative server indicates support for DNS Error Reporting by 143 including an EDNS0 option with OPTION-CODE [TBD] [RFC Editor: change 144 TBD to the proper code when assigned by IANA.] and the REPORTING 145 AGENT DOMAIN in DNS wireformat in the option's payload. The 146 authoritative server MUST NOT include this option in the response if 147 the configured reporting agent domain is empty or the null label (the 148 root). 150 When a reporting resolver sends a reporting query to report an error, 151 it MUST NOT include the EDNS0 Error Reporting option in the reporting 152 query. This avoids additional compounding error reporting when there 153 is an issue with the reporting agent domain. 155 To report an error, the reporting resolver encodes the error report 156 in the QNAME of the reporting query. The reporting resolver builds 157 this QNAME by concatenating the _er label, the extended error code 158 [RFC8914], the QTYPE and the QNAME that resulted in failure, the 159 label "_er" again, and the reporting agent domain. See the example 160 in section 4.2. Note that a regular RCODE is not included, as the 161 RCODE is not relevant to the extended error code. 163 The resulting concatenated domain name is sent as a standard DNS 164 query for DNS resource record type NULL by the reporting resolver. 165 This query MUST NOT have the EDNS0 option code [TBD] set to avoid 166 compounding error notifications. 168 The query will ultimately arrive at the authoritative server for the 169 reporting agent domain. A NODATA negative response is returned by 170 the authoritative server of the reporting agent domain, which in turn 171 can be cached by the reporting resolver. 173 This caching is essential. It ensures that the number of reports 174 sent by a reporting resolver for the same problem is dampened, i.e. 175 once per TTL, however, certain optimizations such as [RFC8020] and 176 [RFC8198] may reduce the number of error reporting queries as well. 178 4.1. Managing Caching Optimizations 180 The reporting resolver may utilize various caching optimizations that 181 inhibit subsequent error reporting to the same reporting agent 182 domain. 184 If the authoritative server for the reporting agent domain were to 185 respond with NXDOMAIN (name error), [RFC8020] rules state that any 186 name at or below that domain should be considered unreachable, and 187 negative caching would prohibit subsequent queries for anything at or 188 below that domain for a period of time, depending on the negative TTL 189 [RFC2308]. 191 Since the authoritative server for an agent domain may not know the 192 contents of all the zones it acts as an agent for, it is essential 193 that the authoritative server does not respond with NXDOMAIN, as that 194 may inhibit subsequent queries. The use of a wildcard domain name 195 [RFC4592] in the zone for the agent domain will ensure the RCODE is 196 consistently NOERROR. 198 Considering the Resource Record type for this wildcard record, type 199 NULL is prohibited in master zone files [RFC1035]. However, any type 200 that is not special according to [RFC4592] section 4 will do, such as 201 a TXT record with an email address for the reporting agent in the 202 RDATA. 204 Wildcard expansion occurs, even if the QTYPE is not for the type 205 owned by the wildcard domain name. The response is a "no error, but 206 no data" response ([RFC4592], section 2.2.1.) that contains a NOERROR 207 RCODE and empty answer section. Note that reporting resolvers are 208 not expected to query for this TXT record, since reporting queries 209 use type NULL. This record is solely present to ensure a NODATA 210 response is returned in response to reporting queries. 212 When the zone for the reporting agent domain is signed, a resolver 213 may utilize aggressive negative caching, discussed in [RFC8198]. 214 This optimization makes use of NSEC and NSEC3 (without opt-out) 215 records and allows the resolver to do the wildcard synthesis. When 216 this happens, the resolver may not send subsequent queries as it will 217 be able to synthesize a response from previously cached material. 219 A solution is to avoid DNSSEC for the reporting agent domain. 220 Signing the agent domain will incur an additional burden on the 221 reporting resolver, as it has to validate the response. However, 222 this response has no utility to the reporting resolver. 224 4.2. Example 226 The domain broken.test is hosted on a set of authoritative servers. 227 One of these serves a stale version. This authoritative server has a 228 reporting agent configured: a01.reporting-agent.example. 230 The reporting resolver is unable to validate the broken.test RRSet 231 for type A, due to an RRSIG record with an expired signature. 233 The reporting resolver constructs the QNAME 234 _er.7.1.broken.test._er.a01.reporting-agent.example and resolves it. 236 This QNAME indicates extended DNS error 7 occurred while trying to 237 validate broken.test type 1 (A) record. 239 After this query is received at one of the authoritative servers for 240 the reporting agent domain (a01.reporting-agent.example), the 241 reporting agent (the operators of the authoritative server for 242 a01.reporting-agent.example) determines that the authoritative server 243 for the broken.test zone suffers from an expired signature record 244 (extended error 7) for type A for the domain name broken.test. The 245 reporting agent can contact the operators of broken.test to fix the 246 issue. 248 5. EDNS0 Option Specification 250 This method uses an EDNS0 [RFC6891] option to indicate support for 251 sending DNS error reports and responding with the Reporting Agent 252 Domain in DNS messages. The option is structured as follows: 254 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OPTION-CODE = TBD | OPTION-LENGTH | 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 259 / REPORTING AGENT DOMAIN / 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 262 Field definition details: 264 o OPTION-CODE, 2-octets/16-bits (defined in [RFC6891]), for 265 indicating error reporting support is TBD. [RFC Editor: change 266 TBD to the proper code when assigned by IANA.] 268 o OPTION-LENGTH, 2-octets/16-bits ((defined in [RFC6891]) contains 269 the length of the REPORTING AGENT DOMAIN field in octets. 271 o REPORTING AGENT DOMAIN, a Domain name [RFC8499] in the DNS wire 272 format prescribed by [RFC1035]. 274 6. DNS Error Reporting Specification 276 The various errors that a reporting resolver may encounter are listed 277 in [RFC8914]. Note that not all listed errors may be supported by 278 the reporting resolver. This document does not specify what is an 279 error and what is not. 281 The DNS class is not specified in the error report. 283 6.1. Reporting Resolver Specification 285 Reporting Resolvers may have a configuration that allows the 286 following: 288 The reporting resolver MUST NOT use DNS error reporting to report a 289 failure in resolving the reporting query. 291 The reporting resolver MUST NOT use DNS error reporting if the 292 authoritative server has an empty Reporting Agent Domain field in the 293 EDNS Error Reporting option. 295 6.1.1. Constructing the Reporting Query 297 The QNAME for the reporting query is constructed by concatenating the 298 following elements, appending each successive element in the list to 299 the right-hand side of the QNAME: 301 o A label containing the string "_er". 303 o The Extended DNS error, presented as a decimal value, in a single 304 DNS label. 306 o The QTYPE that was used in the query that resulted in the extended 307 DNS error, presented as a decimal value, in a single DNS label. 309 o The QNAME that was used in the query that resulted in the extended 310 DNS error. The QNAME may consist of multiple labels and is 311 concatenated as is, i.e. in DNS wire format. 313 o A label containing the string "_er". 315 o The reporting agent domain. The reporting agent domain consists 316 of multiple labels and is concatenated exactly as received in the 317 EDNS option sent by the authoritative server. 319 If the resulting reporting query QNAME would exceed 255 octets, it 320 MUST NOT be sent. 322 The "_er" labels allow the reporting agent to quickly differentiate 323 between the agent domain and the faulty query name. When the 324 specified agent domain is empty, or a NULL label (despite being not 325 allowed in this specification), the reporting query will have "_er" 326 as a top-level domain as a result and not the original query. 327 Lastly, the purpose of the first "_er" label is to indicate that a 328 complete reporting query has been received, instead of a shorter 329 reporting query due to query minimization. 331 6.2. Authoritative Server Specification 333 The Authoritative Server SHOULD NOT have multiple reporting agent 334 domains configured for a single zone. To support multiple reporting 335 agents, a single agent can act as a syndicate to subsequently inform 336 additional agents. 338 An authoritative server for a zone with DNS error reporting enabled 339 SHOULD NOT also be authoritative for that zone's reporting agent 340 domain's zone. 342 6.3. Reporting Agent Specification 344 It is RECOMMENDED that the reporting agent zone uses a wildcard DNS 345 record of type TXT with an arbitrary string in the RDATA and a TTL of 346 at least one hour. 348 6.4. Choosing a Reporting Agent Domain 350 It is RECOMMENDED that the reporting agent domain be kept relatively 351 short to allow for a longer QNAME in the reporting query. 353 7. IANA Considerations 355 IANA is requested to assign the following DNS EDNS0 option code 356 registry: 358 Value Name Status Reference 359 ----- ---------------- -------- --------------- 360 TBD DNS ERROR REPORT Standard [this document] 362 [RFC Editor: change TBD to the proper code when assigned by IANA.] 364 IANA is requested to assign the following Underscored and Globally 365 Scoped DNS Node Name registry: 367 RR Type _NODE NAME Reference 368 ----- ---------- --------- 369 TXT _er [this document] 371 8. Security Considerations 373 Use of DNS Error Reporting may expose local configuration mistakes in 374 the reporting resolver, such as stale DNSSEC trust anchors to the 375 reporting agent. 377 DNS Error reporting SHOULD be done using DNS Query Name Minimization 378 [RFC7816] to improve privacy. 380 DNS Error Reporting is done without any authentication between the 381 reporting resolver and the authoritative server of the agent domain. 382 Authentication significantly increases the burden on the reporting 383 resolver without any benefit to the reporting agent, authoritative 384 server or reporting resolver. 386 The method described in this document will cause additional queries 387 by the reporting resolver to authoritative servers in order to 388 resolve the reporting query. 390 This method can be abused by deploying broken zones with agent 391 domains that are delegated to servers operated by the intended victim 392 in combination with open resolvers [RFC8499]. 394 9. Acknowledgements 396 This document is based on an idea by Roy Arends and David Conrad. 397 The authors would like to thank Peter van Dijk, Vladimir Cunat, Paul 398 Hoffman, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, 399 xDick Franks, Benno Overeinder and Petr Spacek for their 400 contributions. 402 10. Informative References 404 [RFC1035] Mockapetris, P., "Domain names - implementation and 405 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 406 November 1987, . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 414 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 415 . 417 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 418 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 419 . 421 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 422 for DNS (EDNS(0))", STD 75, RFC 6891, 423 DOI 10.17487/RFC6891, April 2013, 424 . 426 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 427 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 428 . 430 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 431 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 432 November 2016, . 434 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 435 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 436 July 2017, . 438 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 439 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 440 January 2019, . 442 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 443 Lawrence, "Extended DNS Errors", RFC 8914, 444 DOI 10.17487/RFC8914, October 2020, 445 . 447 Authors' Addresses 449 Roy Arends 450 ICANN 452 Email: roy.arends@icann.org 454 Matt Larson 455 ICANN 457 Email: matt.larson@icann.org