idnits 2.17.1 draft-livingood-dnsop-auth-dnssec-mistakes-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2015) is 3096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5914' is defined on line 239, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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 November 3, 2015 5 Expires: May 6, 2016 7 Responsibility for Authoritative DNSSEC Mistakes 8 draft-livingood-dnsop-auth-dnssec-mistakes-03 10 Abstract 12 DNS Security Extensions (DNSSEC) is now entering widespread 13 deployment. However, domain signing tools and processes are not yet 14 as mature and reliable as is the case for non-DNSSEC-related domain 15 administration tools and processes. Authoritative DNS operators 16 should focus on improving these processes and establishing a high 17 level of quality in their work. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 6, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Domain Validation Failures . . . . . . . . . . . . . . . . . 3 55 3. Responsibility for Failures . . . . . . . . . . . . . . . . . 3 56 4. Comparison to Other DNS Misconfigurations . . . . . . . . . . 4 57 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Security Considerations . . . . . . . . . . . . . . . . . 4 59 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 5 60 5.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 6 66 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 72 related operational practices are defined extensively [RFC1034] 73 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 74 [RFC5155]. 76 DNSSEC has now entered widespread deployment. However, domain 77 signing tools and processes are not yet as mature and reliable as is 78 the case for non-DNSSEC-related domain administration tools and 79 processes. As a result, operators of DNS recursive resolvers, such 80 as Internet Service Providers (ISPs), occasionally observe domains 81 incorrectly managing DNSSEC-related resource records. This 82 mismanagement triggers DNSSEC validation failures, and then causes 83 large numbers of end users to be unable to reach a domain. Many end 84 users tend interpret this as a failure of their DNS servers, and may 85 switch to a non-validating resolver (reducing their security) or 86 contact their ISP to complain, rather than seeing this as a failure 87 on the part of the domain they wanted to reach. 89 This document makes clear, however, that responsibility for these 90 failures rests squarely with authoritative domain name operators, as 91 noted in Section 3. 93 2. Domain Validation Failures 95 A domain name can fail validation for two general reasons, a 96 legitimate security failure such as due to an attack or compromise of 97 some sort, or as a result of misconfiguration on the part of an 98 domain administrator. As domains transition to DNSSEC the most 99 likely reason for a validation failure will be due to 100 misconfiguration. Thus, domain administrators should be sure to read 101 [RFC6781] in full. They should also pay special attention to 102 Section 4.2, pertaining to key rollovers, which appears to be the 103 cause of many recent validation failures. 105 In one recent example [DNSSEC-Validation-Failure-Analysis], a 106 specific domain name failed to validate. An investigation revealed 107 that the domain's administrators performed a Key Signing Key (KSK) 108 rollover by (1) generating a new key and (2) signing the domain with 109 the new key. However, they did not use a double-signing procedure 110 for the KSK and a pre-publish procedure for the ZSK. Double-signing 111 refers to signing a zone with two KSKs and then updating the parent 112 zone with the new DS record so that both keys are valid at the same 113 time. This meant that the domain name was signed with the new KSK, 114 but it was not double-signed with the old KSK. So, the new key was 115 used for signing the zone but the old key was not. As a result, the 116 domain could not be trusted and returned an error when trying to 117 reach the domain. Thus, the domain was in a situation where the 118 DNSSEC chain of trust was broken because the Delegation Signer (DS) 119 record pointed to the old KSK, which was no longer used for signing 120 the zone. (A DS record provides a link in the chain of trust for 121 DNSSEC from the parent zone to the child zone - in this case between 122 TLD and domain name.) 124 3. Responsibility for Failures 126 A domain administrator is solely and completely responsible for 127 managing their domain name(s) and DNS resource records. This 128 includes complete responsibility for the correctness of those 129 resource records, the proper functioning of their authoritative DNS 130 servers, and the correctness of DNS records linking their domain to a 131 top-level domain (TLD) or other higher level domain. The domain 132 owner is also responsible for selection of the authoritative domain 133 administrator, operator, or service provider. Thus, even in cases 134 where some error may be introduced by a third party, whether that is 135 due to an authoritative server software vendor, software tools 136 vendor, domain name registrar, or other organization, these are all 137 parties that the domain administrator has selected and is responsible 138 for managing successfully. 140 There are some cases where the domain administrator is different than 141 the domain owner. In those cases, a domain owner has delegated 142 operational responsibility to the domain administrator. So no matter 143 whether a domain owner is also the domain administrator or not, the 144 domain administrator is nevertheless operationally responsible for 145 the proper configuration operation of the domain. 147 So in the case of a domain name failing to successfully validate, 148 when this is due to a misconfiguration of the domain, that is the 149 sole responsibility of the domain administrator. 151 Any assistance or mitigation responses undertaken by other parties to 152 mitigate the misconfiguration of a domain name by a domain 153 administrator, especially operators of DNS recursive resolvers, are 154 optional and at the pleasure of those parties. 156 4. Comparison to Other DNS Misconfigurations 158 As noted in Section 3 domain administrators are ultimately 159 responsible for managing and ensuring their DNS records are 160 configured correctly. ISPs or other DNS recursive resolver operators 161 cannot and should not correct misconfigured A, CNAME, MX, or other 162 resource records of domains for which they are not authoritative. 163 Expecting non-authoritative entities to protect domain administrators 164 from any misconfiguration of resource records is therefore 165 unrealistic and unreasonable, and in the long-term is harmful to the 166 delegated design of the DNS and could lead to extensive operational 167 instability and/or variation. 169 5. Other Considerations 171 5.1. Security Considerations 173 Authoritative domain name operators and domain name owners, in the 174 case of DNSSEC-related mistakes that cause validation failures to 175 occur, should focus on correcting the issue and then improving their 176 processes and tools in the future. During the period of time that 177 their domain cannot be resolved due to a DNSSEC-related mistake, they 178 should not encourage end users to switch to non-validating resolvers, 179 as the use of a non-validating DNS recursive resolver has 180 comparatively less security capabilities than a validating resolver, 181 since one implements DNS Security Extensions and one does not. In 182 addition, if an end user changes to a non-validating resolver they 183 may subject themselves to increased security risks and threats 184 against which DNS Security Extensions may have provided protection. 186 5.2. Privacy Considerations 188 There are no privacy considerations in this document. 190 5.3. IANA Considerations 192 There are no IANA considerations in this document. 194 6. Acknowledgements 196 - William Brown 198 7. References 200 7.1. Normative References 202 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 203 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 204 . 206 [RFC1035] Mockapetris, P., "Domain names - implementation and 207 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 208 November 1987, . 210 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 211 Rose, "DNS Security Introduction and Requirements", 212 RFC 4033, DOI 10.17487/RFC4033, March 2005, 213 . 215 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 216 Rose, "Resource Records for the DNS Security Extensions", 217 RFC 4034, DOI 10.17487/RFC4034, March 2005, 218 . 220 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 221 Rose, "Protocol Modifications for the DNS Security 222 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 223 . 225 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 226 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 227 . 229 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 230 (DS) Resource Records (RRs)", RFC 4509, 231 DOI 10.17487/RFC4509, May 2006, 232 . 234 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 235 Security (DNSSEC) Hashed Authenticated Denial of 236 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 237 . 239 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 240 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 241 . 243 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 244 Operational Practices, Version 2", RFC 6781, 245 DOI 10.17487/RFC6781, December 2012, 246 . 248 7.2. Informative References 250 [DNSSEC-Validation-Failure-Analysis] 251 Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., 252 and J. Livingood, "Analysis of DNSSEC Validation Failure - 253 NASA.GOV", Comcast , January 2012, 254 . 257 Appendix A. Document Change Log 259 [RFC Editor: This section is to be removed before publication] 261 Individual-00: First version published as an individual draft. 263 Individual-01: Fixed nits identified by William Brown 265 Individual-02: Updated prior to IETF-91 267 WG-00: Renamed at request of DNSOP co-chairs 269 WG-01: Updated doc to keep it from expiring 271 WG-02: Removed RFC 2119 reference in XML 273 WG-03: I should really work on this draft soon 275 Appendix B. Open Issues 277 [RFC Editor: This section is to be removed before publication] 279 No open issues at this time 281 Author's Address 283 Jason Livingood 284 Comcast 285 One Comcast Center 286 1701 John F. Kennedy Boulevard 287 Philadelphia, PA 19103 288 US 290 Email: jason_livingood@cable.comcast.com 291 URI: http://www.comcast.com