idnits 2.17.1 draft-livingood-dnsop-auth-dnssec-mistakes-04.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 223: '...ed mistake, they SHOULD NOT encourage ...' RFC 2119 keyword, line 237: '...rotect their privacy, users SHOULD NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2019) is 1893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-livingood-dnsop-dont-switch-resolvers' is mentioned on line 239, but not defined == Unused Reference: 'I-D.livingood-dnsop-dont-switch-resolvers' is defined on line 309, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-livingood-dnsop-dont-switch-resolvers-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational February 18, 2019 5 Expires: August 22, 2019 7 Responsibility for Authoritative DNS and DNSSEC Mistakes 8 draft-livingood-dnsop-auth-dnssec-mistakes-04 10 Abstract 12 DNS Security Extensions (DNSSEC) validation by recursive DNS 13 resolvers has been deployed at scale. However, domain signing tools 14 and processes are not yet as mature and reliable as is the case for 15 non-DNSSEC-related domain administration tools and processes. This 16 sometimes results in DNSSEC-validation failures, for which operators 17 of validating resolvers are often blamed. This is similar to other, 18 non-DNSSEC-related authoritative DNS errors, for which individual 19 recursive DNS operators are sometimes incorrectly blamed. This 20 document makes clear that responsibility for any and all 21 authoritative DNS failures rests squarely with authoritative domain 22 name operators, who are the only party that can properly maintain 23 their domain names and rectify associated authoritative DNS errors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 22, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Domain Validation Failures . . . . . . . . . . . . . . . . . 3 61 3. Responsibility for Failures . . . . . . . . . . . . . . . . . 4 62 4. Comparison to Other DNS Misconfigurations . . . . . . . . . . 5 63 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Security Considerations . . . . . . . . . . . . . . . . . 5 65 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 5 66 5.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 7 72 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 78 related operational practices are defined extensively [RFC1034] 79 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 80 [RFC5155]. 82 DNS Security Extensions (DNSSEC) validation by recursive DNS 83 resolvers has been deployed at scale. However, domain signing tools 84 and processes are not yet as mature and reliable as is the case for 85 non-DNSSEC-related domain administration tools and processes. This 86 sometimes results in DNSSEC-validation failures, for which operators 87 of validating resolvers are often blamed. This is similar to other, 88 non-DNSSEC-related authoritative DNS errors, for which individual 89 recursive DNS operators are sometimes incorrectly blamed. This 90 documents makes clear that responsibility for any and all 91 authoritative DNS failures rests squarely with authoritative domain 92 name operators, who are the only party that can properly maintain 93 their domain names and rectify associated authoritative DNS errors. 95 Operators of DNS recursive resolvers, including Internet Service 96 Providers (ISPs) and cloud-based DNS resolvers, occasionally observe 97 domains incorrectly managing DNSSEC-related resource records. This 98 mismanagement triggers DNSSEC validation failures, and then causes 99 large numbers of end users to be unable to reach a domain. 100 Similarly, errors in non-DNSSEC-related authoritative DNS resource 101 records result in failures, from NXDOMAIN responses to valid 102 responses containing outdated or unreachable hosts. 104 Many end users, as well as reporters, policymakers, regulators, and 105 others often interpret this as a failure of particular recursive DNS 106 resolvers. Rather than seeing this as a failure on the part of the 107 domain they wanted to reach, they may themselves and/or recommend to 108 others that they switch to a non-validating resolver (which reduces 109 their security), switch to a different DNS resolver (which can reduce 110 non-DNS application layer performance), or contact their ISP or DNS 111 resolver operator to complain. 113 This document makes clear, however, that responsibility for these 114 types of authoritative DNS failures rests squarely with authoritative 115 domain name operators, as noted in Section 3. 117 2. Domain Validation Failures 119 A domain name can fail validation for two general reasons, a 120 legitimate security failure such as due to an attack or compromise of 121 some sort, or as a result of misconfiguration or other error or 122 omission on the part of an domain administrator. As domains 123 transition to DNSSEC the most likely reason for a validation failure 124 during and shortly after the transition is likely due to 125 misconfiguration. Thus, domain administrators should be sure to read 126 [RFC6781] in full. They should also pay special attention to 127 Section 4.2, pertaining to key rollovers, which appears to be the 128 cause of many validation failures. 130 In one example [DNSSEC-Validation-Failure-Analysis], a specific 131 domain name failed to validate. An investigation revealed that the 132 domain's administrators performed a Key Signing Key (KSK) rollover by 133 (1) generating a new key and (2) signing the domain with the new key. 134 However, they did not use a double-signing procedure for the KSK and 135 a pre-publish procedure for the ZSK. Double-signing refers to 136 signing a zone with two KSKs and then updating the parent zone with 137 the new DS record so that both keys are valid at the same time. This 138 meant that the domain name was signed with the new KSK, but it was 139 not double-signed with the old KSK. So, the new key was used for 140 signing the zone but the old key was not. As a result, the domain 141 could not be trusted and returned an error when trying to reach the 142 domain. Thus, the domain was in a situation where the DNSSEC chain 143 of trust was broken because the Delegation Signer (DS) record pointed 144 to the old KSK, which was no longer used for signing the zone. (A DS 145 record provides a link in the chain of trust for DNSSEC from the 146 parent zone to the child zone - in this case between TLD and domain 147 name.) 149 In a non-DNSSEC-related example, a domain administrator may add a new 150 host with an A and AAAA resource record pointing the name to the IP 151 addresses of new servers with a Time To Live (TTL) of two days. But 152 they may turn down the old servers with a similar two day TTL before 153 that TTL has expired. As a result, some number of users are likely 154 to continue to attempt to connect to the old IP addresses that are no 155 longer reachable. While a best practice is to reduce the TTL to a 156 matter of seconds or minutes before such a shift, many domains 157 continue to forget the impact that the TTL can have, or make 158 countless other errors in their domain name, server, and network 159 administration that negatively impacts domain name-based 160 reachability. 162 3. Responsibility for Failures 164 An authoritative domain owner is solely and completely responsible 165 for managing their domain name(s) and associated DNS resource 166 records. This includes complete responsibility for the correctness 167 of those resource records, the proper functioning and reachability of 168 their authoritative DNS servers, and the correctness of DNS records 169 linking their domain to a top-level domain (TLD) or other higher 170 level domain. The domain owner is also responsible for selection of 171 the authoritative domain administrator, operator, or service 172 provider. Thus, even in cases where some error may be introduced by 173 a third party, whether that is due to an authoritative server 174 software vendor, software tools vendor, domain name registrar, 175 Content Delivery Network (CDN), or other organization, these are all 176 parties that the domain owner has selected and is responsible for 177 managing successfully. 179 There are some cases where the domain administrator is different than 180 the domain owner. In those cases, a domain owner has delegated 181 operational responsibility to the domain administrator (and that 182 domain administrator may further delegate some sub-domains and/or 183 records to another party, such as a CDN). So no matter whether a 184 domain owner is also the domain administrator or not, the domain 185 owner and domain administrator are nevertheless operationally 186 responsible for the proper configuration and operation of the domain 187 name . 189 In the case of a domain name failing DNSSEC validation, even when 190 this is due to a misconfiguration of the domain, that is the sole 191 responsibility of the domain owner. 193 Any assistance or mitigation responses undertaken by other parties to 194 mitigate the misconfiguration of a domain name by a domain owner and/ 195 or administrator, especially operators of DNS recursive resolvers, 196 are optional and at the pleasure of those parties. This can the use 197 of a Negative Trust Anchor [RFC7646] and/or clearing the cache in 198 particular DNS resolvers. 200 4. Comparison to Other DNS Misconfigurations 202 As noted in Section 3 domain administrators are ultimately 203 responsible for managing and ensuring their DNS records are 204 configured correctly. ISPs or other DNS recursive resolver operators 205 cannot and should not correct misconfigured A, CNAME, MX, or other 206 resource records of domains for which they are not authoritative. 207 Expecting non-authoritative entities to protect domain owners and 208 administrators from any misconfiguration of resource records is 209 therefore unrealistic and unreasonable, does not scale well, and is 210 strongly contrary to the delegated design of the DNS and could lead 211 to extensive operational instability and/or variation. 213 5. Other Considerations 215 5.1. Security Considerations 217 Authoritative domain name owners and/or administrators, in the case 218 of DNSSEC-related mistakes that cause validation failures to occur, 219 should focus on correcting the immediate authoritative DNS issue and 220 then improving their processes and tools in the future. 222 During the period of time that their domain cannot be resolved due to 223 a DNSSEC-related mistake, they SHOULD NOT encourage end users to 224 switch to non-validating resolvers [I-D.draft-livingood-dnsop-dont- 225 switch-resolvers] . 227 5.2. Privacy Considerations 229 In the case of a DNSSEC validation failure, if an end user changes to 230 a non-validating resolver they can subject themselves to increased 231 security risks and threats against which DNSSEC may have provided 232 protection. This can include threats to their privacy, such as by 233 unwittingly visiting a phishing site and sharing sensitive data or 234 other private information with a malicious party or some party other 235 than that which was originally intended. 237 As a result, in order to protect their privacy, users SHOULD NOT 238 switch to a non-validating resolver when a DNSSEC validation failure 239 occurs [I-D.draft-livingood-dnsop-dont-switch-resolvers]. 241 5.3. IANA Considerations 243 There are no IANA considerations in this document. 245 6. Acknowledgements 247 - William Brown 249 7. References 251 7.1. Normative References 253 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 254 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 255 . 257 [RFC1035] Mockapetris, P., "Domain names - implementation and 258 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 259 November 1987, . 261 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 262 Rose, "DNS Security Introduction and Requirements", 263 RFC 4033, DOI 10.17487/RFC4033, March 2005, 264 . 266 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 267 Rose, "Resource Records for the DNS Security Extensions", 268 RFC 4034, DOI 10.17487/RFC4034, March 2005, 269 . 271 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 272 Rose, "Protocol Modifications for the DNS Security 273 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 274 . 276 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 277 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 278 . 280 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 281 (DS) Resource Records (RRs)", RFC 4509, 282 DOI 10.17487/RFC4509, May 2006, 283 . 285 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 286 Security (DNSSEC) Hashed Authenticated Denial of 287 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 288 . 290 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 291 Operational Practices, Version 2", RFC 6781, 292 DOI 10.17487/RFC6781, December 2012, 293 . 295 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 296 and R. Weber, "Definition and Use of DNSSEC Negative Trust 297 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 298 . 300 7.2. Informative References 302 [DNSSEC-Validation-Failure-Analysis] 303 Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., 304 and J. Livingood, "Analysis of DNSSEC Validation Failure - 305 NASA.GOV", Comcast , January 2012, 306 . 309 [I-D.livingood-dnsop-dont-switch-resolvers] 310 Livingood, J., "In Case of DNSSEC Validation Failures, Do 311 Not Change Resolvers", draft-livingood-dnsop-dont-switch- 312 resolvers-03 (work in progress), November 2015. 314 Appendix A. Document Change Log 316 [RFC Editor: This section is to be removed before publication] 318 Individual-00: First version published as an individual draft. 320 Individual-01: Fixed nits identified by William Brown 322 Individual-02: Updated prior to IETF-91 324 WG-00: Renamed at request of DNSOP co-chairs 326 WG-01: Updated doc to keep it from expiring 328 WG-02: Removed RFC 2119 reference in XML 330 WG-03 to 04: Refreshed draft and broadened to all auth issues, not 331 just DNSSEC. 333 Appendix B. Open Issues 335 [RFC Editor: This section is to be removed before publication] 337 Fix I-D xref 339 Author's Address 341 Jason Livingood 342 Comcast 344 Email: jason_livingood@comcast.com