idnits 2.17.1 draft-ietf-dnsop-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: ---------------------------------------------------------------------------- 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 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 (April 27, 2021) is 1095 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 (~~), 3 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: October 29, 2021 April 27, 2021 7 DNS Error Reporting 8 draft-ietf-dnsop-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 October 29, 2021. 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 . . . . . . . . . . . . . 5 65 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. EDNS0 Option Specification . . . . . . . . . . . . . . . . . 6 67 6. DNS Error Reporting Specification . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 9 73 7. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 11. Informative References . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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] in the format 283 prescribed by [RFC1035]. 285 6. DNS Error Reporting Specification 287 The various errors that a reporting resolver may encounter are listed 288 in [RFC8914]. Note that not all listed errors may be supported by 289 the reporting resolver. This document does not specify what is an 290 error and what is not. 292 The DNS class is not specified in the error report. 294 6.1. Reporting Resolver Specification 296 Reporting Resolvers may have a configuration that allows the 297 following: 299 o DNS Error Reporting level: warning and / or errors 301 o Do nothing: the reporting resolver does not indicate support for 302 DNS Error Reporting. 304 o Report to Reporting Agent: Indicate DNS Error Reporting in queries 305 and use the reporting agent specified in the EDNS0 option received 306 from the authoritative server. 308 o Report to Configured Agent: Use the reporting agent specified in 309 local configuration. This may override or supplement "Reporting 310 Agent Domain". The use for such an option could be to allow a 311 recursive resolver to report all errors to a reporting agent of 312 its choosing, not just in zones with DNS Error Reporting enabled. 314 The reporting resolver MUST NOT use DNS error reporting to report a 315 failure in resolving the reporting query. 317 The reporting resolver MUST NOT use DNS error reporting if the 318 authoritative server has an empty Reporting Agent Domain field in the 319 EDNS Error Reporting option. 321 6.1.1. Constructing the Reporting Query 323 The QNAME for the reporting query is constructed by concatenating the 324 following elements, appending each successive element in the list to 325 the right-hand side of the QNAME: 327 o The Extended DNS error, presented as a decimal value, in a single 328 DNS label. 330 o The QTYPE that was used in the query that resulted in the extended 331 DNS error, presented as a decimal value, in a single DNS label. 333 o The QNAME that was used in the query that resulted in the extended 334 DNS error. The QNAME may consist of multiple labels and is 335 concatenated as-is. 337 o A label containing the string "_er". 339 o The reporting agent domain. The reporting agent domain consists 340 of multiple labels and is concatenated exactly as received in the 341 EDNS option sent by the authoritative server. 343 If the resulting reporting query QNAME would exceed 255 octets, it 344 MUST NOT be sent. 346 The purpose of the "_er" label is twofold. First, it allows the 347 reporting agent to quickly differentiate between the agent domain and 348 the faulty query name. Second, if the specified agent domain is 349 empty, or a NULL label (even if it is not allowed in this 350 specification), the reporting query will have "_er" as a top-level 351 domain as a result and not the original query. 353 6.2. Authoritative Server Specification 355 The Authoritative Server MUST NOT have multiple reporting agent 356 domains configured for a single zone. To support multiple reporting 357 agents, a single agent can act as a syndicate to subsequently inform 358 additional agents. 360 An authoritative server for a zone with DNS error reporting enabled 361 MUST NOT also be authoritative for that zone's reporting agent 362 domain's zone. 364 6.3. Reporting Agent Specification 366 While there are many zone configurations possible for the reporting 367 agent domain, such as DNAME, CNAME or special delegation structures 368 to redistribute errors, please note that the burden of reporting is 369 on the reporting resolvers and that creating complicated 370 configurations that cause additional work for the reporting resolver 371 on behalf of misconfigured servers is NOT RECOMMENDED. 373 It is RECOMMENDED that the reporting agent zone uses a wildcard DNS 374 record of type TXT with an arbitrary string in the RDATA and a TTL of 375 at least one hour. 377 6.4. Choosing a Reporting Agent Domain 379 Each authoritative server SHOULD be configured with a unique 380 reporting agent domain. When different authoritative servers share 381 the same reporting agent domain, it is not possible to determine 382 which authoritative server the reported error relates to. 384 It is RECOMMENDED that the reporting agent domain be kept relatively 385 short to allow for a longer QNAME in the reporting query. 387 While it may be obvious to use the hostname of the authoritative 388 server as the reporting agent domain, it is not a requirement, as 389 long as the reporting agent is able to map the reporting agent domain 390 to the proper authoritative server. Using the hostname of the 391 authoritative server as the reporting agent domain is NOT RECOMMENDED 392 when the hostname has multiple addresses, or when addresses are 393 anycast. 395 7. Limitations 397 The length of the owner name for which errors can be reported is 398 limited due to the requirement to append the reporting agent domain 399 and prepend the Extended Error value and the QTYPE to the reporting 400 query's QNAME. 402 8. IANA Considerations 404 IANA is requested to assign the following DNS EDNS0 option code 405 registry: 407 Value Name Status Reference 408 ----- ---------------- -------- --------------- 409 TBD DNS ERROR REPORT Standard [this document] 411 [RFC Editor: change TBD to the proper code when assigned by IANA.] 413 IANA is requested to assign the following Underscored and Globally 414 Scoped DNS Node Name registry: 416 RR Type _NODE NAME Reference 417 ----- ---------- --------- 418 TXT _er [this document] 420 9. Security Considerations 422 Use of DNS Error Reporting may expose local configuration mistakes in 423 the reporting resolver, such as stale DNSSEC trust anchors to the 424 reporting agent. 426 DNS Error reporting SHOULD be done using DNS Query Name Minimization 427 [RFC7816] to improve privacy. 429 DNS Error Reporting is done without any authentication between the 430 reporting resolver and the authoritative server of the agent domain. 431 Authentication significantly increases the burden on the reporting 432 resolver without any benefit to the reporting agent, authoritative 433 server or reporting resolver. 435 The reporting resolver MUST NOT report about queries and responses 436 from an encrypted channel (such as DNS over TLS [RFC7858] and DNS 437 over HTTPS [RFC8484]). 439 The reporting resolver MUST NOT report about responses that did not 440 match the qname/qtype/qclass and query-id in the original query 441 [RFC5452], section 4.2. 443 The method described in this document will cause additional queries 444 by the reporting resolver to authoritative servers in order to 445 resolve the reporting query. This additional load is equivalent to 446 the additional load when a resolver resolves the canonical name in a 447 CNAME record. 449 This method can be abused by deploying broken zones with agent 450 domains that are delegated to servers operated by the intended victim 451 in combination with open resolvers [RFC8499]. This method MUST NOT 452 be deployed by default on reporting resolvers and authoritative 453 servers without requiring an explicit configuration element. 455 10. Acknowledgements 457 This document is based on an idea by Roy Arends and David Conrad. 458 The authors would like to thank Dick Franks for their contributions. 460 11. Informative References 462 [RFC1035] Mockapetris, P., "Domain names - implementation and 463 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 464 November 1987, . 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 472 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 473 . 475 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 476 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 477 . 479 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 480 Resilient against Forged Answers", RFC 5452, 481 DOI 10.17487/RFC5452, January 2009, 482 . 484 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 485 for DNS (EDNS(0))", STD 75, RFC 6891, 486 DOI 10.17487/RFC6891, April 2013, 487 . 489 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 490 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 491 . 493 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 494 and P. Hoffman, "Specification for DNS over Transport 495 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 496 2016, . 498 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 499 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 500 November 2016, . 502 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 503 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 504 July 2017, . 506 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 507 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 508 . 510 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 511 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 512 January 2019, . 514 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 515 Lawrence, "Extended DNS Errors", RFC 8914, 516 DOI 10.17487/RFC8914, October 2020, 517 . 519 Authors' Addresses 521 Roy Arends 522 ICANN 524 Email: roy.arends@icann.org 526 Matt Larson 527 ICANN 529 Email: matt.larson@icann.org