idnits 2.17.1 draft-arends-dns-error-reporting-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 533 lines 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 28, 2020) is 1277 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 173, 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 (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission R. Arends 3 Internet-Draft M. Larson 4 Intended status: Standards Track ICANN 5 Expires: May 1, 2021 October 28, 2020 7 DNS Error Reporting 8 draft-arends-dns-error-reporting-00 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 1, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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 61 2. Requirements Notation 62 3. Terminology 63 4. Overview 64 4.1. Managing Caching Optimizations 65 4.2. Example 66 5. EDNS0 Option Specification 67 6. DNS Error Reporting Specification 68 6.1. Reporting Resolver Specification 69 6.1.1. Constructing the Reporting Query 70 6.2. Authoritative Server Specification 71 6.3. Reporting Agent Specification 72 6.4. Choosing a Reporting Agent Domain 73 7. Limitations 74 8. IANA Considerations 75 9. Security Considerations 76 10. Acknowledgements 77 11. Informative References 78 Authors' Addresses 80 1. Introduction 82 When an authoritative server serves a stale DNSSEC signed zone, the 83 cryptographic signatures over the resource record sets (RRsets) may 84 have lapsed. A validating recursive resolver will fail to validate 85 these resource records. 87 Similarly, when there is a mismatch between the DS records at a 88 parent zone and the key signing key at the child zone, a validating 89 recursive resolver will fail to authenticate records in the child 90 zone. 92 These are two of several failure scenarios that may go unnoticed for 93 some time by the operator of a zone. 95 There is no direct relationship between operators of validating 96 recursive resolvers and authoritative servers. Outages are often 97 noticed indirectly, by end users, and reported via social media, if 98 reported at all. 100 When records fail to validate there is no facility to report this 101 failure in an automated way. If there is any indication that an 102 error or warning has happened, it is buried in log files of the 103 validating resolver, if these errors are logged at all. 105 This document describes a facility that can be used by validating 106 recursive resolvers to report errors in an automated way. 108 It allows an authoritative server to signal a reporting agent where 109 the validating recursive resolver can report issues if it is 110 configured to do so. 112 The burden of reporting a failure falls on the validating recursive 113 resolver. It is important that the effort needed to report failure 114 is low, with minimal impact to its main functions. To accomplish 115 this goal, the DNS itself is utilized to report the error. 117 2. Requirements Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Terminology 125 Reporting Resolver: In the context of this document, the term 126 reporting resolver is used as a shorthand for a validating recursive 127 resolver that supports DNS Error Reporting. 129 Reporting Query: The DNS query used to report an error is called a 130 reporting query. A reporting query is for DNS resource record type 131 NULL. The details of the error report are encoded in the QNAME of 132 the reporting query. 134 Reporting Agent: A facility responsible for receiving error reports 135 on behalf of authoritative servers. This facility is indicated by a 136 domain name. 138 Reporting Agent Domain: a domain name which the reporting resolver 139 includes in the QNAME of the reporting query. 141 4. Overview 143 In a query-response exchange, a reporting resolver indicates support 144 for DNS Error Reporting by including an EDNS option with OPTION-CODE 145 [TBD] [RFC Editor: change TBD to the proper code when assigned by 146 IANA.] and OPTION-LENGTH zero. The REPORTING AGENT DOMAIN field in 147 the EDNS option is absent in a query. 149 An authoritative server indicates support for DNS Error Reporting by 150 including an EDNS0 option with OPTION-CODE [TBD] [RFC Editor: change 151 TBD to the proper code when assigned by IANA.] and the REPORTING 152 AGENT DOMAIN in the option's payload. The authoritative server MUST 153 NOT include this option if the reporting resolver has not signalled 154 support for DNS Error Reporting. The authoritative server MUST NOT 155 include this option in the response if the configured reporting agent 156 domain is empty or the null label (the root). 158 When a reporting resolver sends a reporting query to report an error, 159 it MUST NOT include the EDNS0 Error Reporting option in the reporting 160 query. This avoids additional compounding error reporting when the 161 reporting agent server is misconfigured. 163 To report an error, the reporting resolver encodes the error report 164 in the QNAME of the reporting query. The reporting resolver builds 165 this QNAME by concatenating the extended error code [RFC8914], the 166 QTYPE and QNAME that resulted in failure, the label "_er", and the 167 reporting agent domain. See the example in section 4.2. Note that a 168 regular RCODE is not included, as the RCODE is not relevant to the 169 extended error code. 171 The resulting concatenated domain name is sent as a standard DNS 172 query for DNS resource record type NULL by the reporting resolver. 173 This query MUST NOT have the EDNS0 option code [TBD] set to avoid 174 compounding error notifications. 176 The query will ultimately arrive at an authoritative server of the 177 reporting agent. A NODATA negative response is returned by the 178 authoritative server of the reporting agent domain, which in turn can 179 be cached by the reporting resolver. 181 This caching is essential. It ensures that the number of reports 182 sent by a reporting resolver for the same problem is dampened, i.e. 183 once per TTL, however, certain optimizations such as [RFC8020] and 184 [RFC8198] may reduce the error reporting. 186 4.1. Managing Caching Optimizations 188 The reporting resolver may utilize various caching optimizations that 189 inhibit subsequent error reporting by the reporting resolver to the 190 authoritative server for an agent domain. 192 If the authoritative server for the agent domain were to respond with 193 NXDOMAIN (name error), [RFC8020] rules state that any name at or 194 below that domain should be considered unreachable, and negative 195 caching would prohibit subsequent queries for anything at or below 196 that domain for a period of time, depending on the negative TTL 197 [RFC2308]. 199 Since the authoritative server for an agent domain may not know the 200 contents of all the zones it acts as an agent for, it is crucial that 201 the authoritative does not respond with NXDOMAIN, as that may inhibit 202 subsequent queries. The use of a wildcard domain name [RFC4592] in 203 the zone for the agent domain will ensure the RCODE is consistently 204 NOERROR. 206 Considering the Resource Record type for this wildcard record, type 207 NULL is prohibited in master zone files [RFC1035]. However, any type 208 that is not special according to [RFC4592] section 4 will do, such as 209 a TXT record with an email address for the reporting agent in the 210 RDATA. 212 Wildcard expansion occurs, even if the QTYPE is not for the type 213 owned by the wildcard domain name. The response is a "no error, but 214 no data" response ([RFC4592], section 2.2.1.) that contains a NOERROR 215 RCODE and empty answer section. Note that reporting resolvers are 216 not expected to query for this TXT record, since reporting queries 217 use type NULL. This record is solely present to ensure a NODATA 218 response is returned in response to reporting queries. 220 When the zone for the reporting agent domain is signed, a resolver 221 may utilize aggressive negative caching, discussed in [RFC8198]. 222 This optimization makes use of NSEC and NSEC3 (without opt-out) 223 records and allows the resolver to do the wildcard synthesis. When 224 this happens, the resolver may not send subsequent queries as it will 225 be able to synthesize a response from previously cached material. 227 A solution is to avoid DNSSEC for the reporting agent domain's zone. 228 Signing the agent domain's zone will incur an additional burden on 229 the reporting resolver, as it has to validate the response. However, 230 this response has no utility to the reporting resolver. 232 If an operator does sign a reporting agent domain's zone for whatever 233 reason, one option is to use NSEC3 with opt-out, as that 234 configuration precludes wildcard synthesis on the resolver. 236 4.2. Example 238 The domain broken.test is hosted on a set of authoritative servers. 239 One of these serves a stale version. This authoritative server has a 240 reporting agent configured: a01.reporting-agent.example. 242 The reporting resolver is unable to validate the broken.test RRSet 243 for type A, due to an RRSIG record with an expired signature. 245 The reporting resolver constructs the QNAME 246 7.1.broken.test._er.a01.reporting-agent.example and resolves it. 247 This QNAME indicates extended DNS error 7 occurred while trying to 248 validate broken.test type 1 (A) record. 250 After this query is received at one of the authoritative servers for 251 the reporting agent domain (a01.reporting-agent.example), the 252 reporting agent (the operators of the authoritative server for 253 a01.reporting-agent.example) determines that the authoritative server 254 for the broken.test zone suffers from an expired signature record 255 (extended error 7) for type A for the domain name broken.test. The 256 reporting agent can contact the operators of broken.test to fix the 257 issue. 259 5. EDNS0 Option Specification 261 This method uses an EDNS0 [RFC6891] option to indicate support for 262 sending DNS error reports and responding with the Reporting Agent 263 Domain in DNS messages. The option is structured as follows: 265 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | OPTION-CODE = TBD | OPTION-LENGTH | 269 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 270 / REPORTING AGENT DOMAIN / 271 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 273 Field definition details: 275 o OPTION-CODE, 2-octets/16-bits (defined in [RFC6891]), for 276 indicating error reporting support is TBD. [RFC Editor: change 277 TBD to the proper code when assigned by IANA.] 279 o OPTION-LENGTH, 2-octets/16-bits ((defined in [RFC6891]) contains 280 the length of the REPORTING AGENT DOMAIN field in octets. 282 o REPORTING AGENT DOMAIN, a Domain name [RFC8499]. 284 6. DNS Error Reporting Specification 286 The various errors that a reporting resolver may encounter are listed 287 in [RFC8914]. Note that not all listed errors may be supported by 288 the reporting resolver. This document does not specify what is an 289 error and what is not. 291 The DNS class is not specified in the error report. 293 6.1. Reporting Resolver Specification 295 Reporting Resolvers may have a configuration that allows the 296 following: 298 o DNS Error Reporting level: warning and / or errors 300 o Do nothing: the reporting resolver does not indicate support for 301 DNS Error Reporting. 303 o Report to Reporting Agent: Indicate DNS Error Reporting in queries 304 and use the reporting agent specified in the EDNS0 option received 305 from the authoritative server. 307 o Report to Configured Agent: Use the reporting agent specified in 308 local configuration. This may override or supplement "Reporting 309 Agent Domain". The use for such an option could be to allow a 310 recursive resolver to report all errors to a reporting agent of 311 its choosing, not just in zones with DNS Error Reporting enabled. 313 The reporting resolver MUST NOT use DNS error reporting to report a 314 failure in resolving the reporting query. 316 The reporting resolver MUST NOT use DNS error reporting if the 317 authoritative server has an empty Reporting Agent Domain field in the 318 EDNS Error Reporting option. 320 6.1.1. Constructing the Reporting Query 322 The QNAME for the reporting query is constructed by concatenating the 323 following elements, appending each successive element in the list to 324 the right-hand side of the QNAME: 326 o The Extended DNS error, presented as a decimal value, in a single 327 DNS label. 329 o The QTYPE that was used in the query that resulted in the extended 330 DNS error, presented as a decimal value, in a single DNS label. 332 o The QNAME that was used in the query that resulted in the extended 333 DNS error. The QNAME may consist of multiple labels and is 334 concatenated as-is. 336 o A label containing the string "_er". 338 o The reporting agent domain. The reporting agent domain consists 339 of multiple labels and is concatenated exactly as received in the 340 EDNS option sent by the authoritative server. 342 If the resulting reporting query QNAME would exceed 255 octets, it 343 MUST NOT be sent. 345 The purpose of the "_er" label is twofold. First, it allows the 346 reporting agent to quickly differentiate between the agent domain and 347 the faulty query name. Second, if the specified agent domain is 348 empty, or a NULL label (even if it is not allowed in this 349 specification), the reporting query will have "_er" as a top-level 350 domain as a result and not the original query. 352 6.2. Authoritative Server Specification 354 The Authoritative Server MUST NOT have multiple reporting agent 355 domains configured for a single zone. To support multiple reporting 356 agents, a single agent can act as a syndicate to subsequently inform 357 additional agents. 359 An authoritative server for a zone with DNS error reporting enabled 360 MUST NOT also be authoritative for that zone's reporting agent 361 domain's zone. 363 6.3. Reporting Agent Specification 365 While there are many zone configurations possible for the reporting 366 agent domain, such as DNAME, CNAME or special delegation structures 367 to redistribute errors, please note that the burden of reporting is 368 on the reporting resolvers and that creating complicated 369 configurations that cause additional work for the reporting resolver 370 on behalf of misconfigured servers is NOT RECOMMENDED. 372 It is RECOMMENDED that the reporting agent zone uses a wildcard DNS 373 record of type TXT with an arbitrary string in the RDATA and a TTL of 374 at least one hour. 376 6.4. Choosing a Reporting Agent Domain 378 Each authoritative server SHOULD be configured with a unique 379 reporting agent domain. When different authoritative servers share 380 the same reporting agent domain, it is not possible to determine 381 which authoritative server the reported error relates to. 383 It is RECOMMENDED that the reporting agent domain be kept relatively 384 short to allow for a longer QNAME in the reporting query. 386 While it may be obvious to use the hostname of the authoritative 387 server as the reporting agent domain, it is not a requirement, as 388 long as the reporting agent is able to map the reporting agent domain 389 to the proper authoritative server. Using the hostname of the 390 authoritative server as the reporting agent domain is NOT RECOMMENDED 391 when the hostname has multiple addresses, or when addresses are 392 anycast. 394 7. Limitations 396 The length of the owner name for which errors can be reported is 397 limited due to the requirement to append the reporting agent domain 398 and prepend the Extended Error value and the QTYPE to the reporting 399 query's QNAME. 401 8. IANA Considerations 403 IANA is requested to assign the following DNS EDNS0 option code 404 registry: 406 Value Name Status Reference 407 ----- ---------------- -------- --------------- 408 TBD DNS ERROR REPORT Standard [this document] 410 [RFC Editor: change TBD to the proper code when assigned by IANA.] 412 IANA is requested to assign the following Underscored and Globally 413 Scoped DNS Node Name registry: 415 RR Type _NODE NAME Reference 416 ----- ---------- --------- 417 TXT _er [this document] 419 9. Security Considerations 421 Use of DNS Error Reporting may expose local configuration mistakes in 422 the reporting resolver, such as stale DNSSEC trust anchors to the 423 reporting agent. 425 DNS Error reporting SHOULD be done using DNS Query Name Minimization 426 [RFC7816] to improve privacy. 428 DNS Error Reporting is done without any authentication between the 429 reporting resolver and the authoritative server of the agent domain. 430 Authentication significantly increases the burden on the reporting 431 resolver without any benefit to the reporting agent, authoritative 432 server or reporting resolver. 434 The reporting resolver MUST NOT report about queries and responses 435 from an encrypted channel (such as DNS over TLS [RFC7858] and DNS 436 over HTTPS [RFC8484]). 438 The reporting resolver MUST NOT report about responses that did not 439 match the qname/qtype/qclass and query-id in the original query 440 [RFC5452], section 4.2. 442 The method described in this document will cause additional queries 443 by the reporting resolver to authoritative servers in order to 444 resolve the reporting query. This additional load is equivalent to 445 the additional load when a resolver resolves the canonical name in a 446 CNAME record. 448 This method can be abused by deploying broken zones with agent 449 domains that are delegated to servers operated by the intended victim 450 in combination with open resolvers [RFC8499]. This method MUST NOT 451 be deployed by default on reporting resolvers and authoritative 452 servers without requiring an explicit configuration element. 454 10. Acknowledgements 456 This document is based on an idea by Roy Arends and David Conrad. 458 11. Informative References 460 [RFC1035] Mockapetris, P., "Domain names - implementation and 461 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 462 November 1987, . 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 470 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 471 . 473 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 474 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 475 . 477 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 478 Resilient against Forged Answers", RFC 5452, 479 DOI 10.17487/RFC5452, January 2009, 480 . 482 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 483 for DNS (EDNS(0))", STD 75, RFC 6891, 484 DOI 10.17487/RFC6891, April 2013, 485 . 487 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 488 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 489 . 491 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 492 and P. Hoffman, "Specification for DNS over Transport 493 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 494 2016, . 496 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 497 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 498 November 2016, . 500 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 501 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 502 July 2017, . 504 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 505 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 506 . 508 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 509 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 510 January 2019, . 512 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 513 Lawrence, "Extended DNS Errors", RFC 8914, 514 DOI 10.17487/RFC8914, October 2020, 515 . 517 Authors' Addresses 519 Roy Arends 520 ICANN 522 Email: roy.arends@icann.org 524 Matt Larson 525 ICANN 527 Email: matt.larson@icann.org