idnits 2.17.1 draft-livingood-dnsop-dont-switch-resolvers-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 290 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2015) is 3321 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5914' is defined on line 246, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6781 Summary: 2 errors (**), 0 flaws (~~), 3 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: Best Current Practice March 23, 2015 5 Expires: September 22, 2015 7 In Case of DNSSEC Validation Failures, Do Not Change Resolvers 8 draft-livingood-dnsop-dont-switch-resolvers-01 10 Abstract 12 DNS Security Extensions (DNSSEC) is beginning widespread deployment. 13 However, domain signing tools and processes are not yet as mature and 14 reliable as is the case for non-DNSSEC-related domain administration 15 tools and processes. As a result, some DNSSEC validation failures 16 may occur. When these failures do occur, end users SHOULD NOT change 17 to a non-validating DNS resolver. 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 September 22, 2015. 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 (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology 53 2. Introduction 54 3. Domain Validation Failures 55 4. Misunderstanding DNSSEC Validation Failures 56 5. Comparison to Other DNS Misconfigurations 57 6. Switching to a Non-Validating Resolver is NOT Recommended 58 7. Other Considerations 59 7.1. Security Considerations 60 7.2. Privacy Considerations 61 7.3. IANA Considerations 62 8. Acknowledgements 63 9. References 64 Appendix A. Document Change Log 65 Appendix B. Open Issues 66 Author's Address 68 Domain Name System Operations J. Livingood 69 Internet-Draft Comcast 70 Intended status: Best Current Practice March 23, 2015 71 Expires: September 22, 2015 73 In Case of DNSSEC Validation Failures, Do Not Change Resolvers 74 draft-livingood-dnsop-dont-switch-resolvers-01 76 Abstract 78 DNS Security Extensions (DNSSEC) is beginning widespread deployment. 79 However, domain signing tools and processes are not yet as mature and 80 reliable as is the case for non-DNSSEC-related domain administration 81 tools and processes. As a result, some DNSSEC validation failures 82 may occur. When these failures do occur, end users SHOULD NOT change 83 to a non-validating DNS resolver. 85 Status of this Memo 87 This Internet-Draft is submitted in full conformance with the 88 provisions of BCP 78 and BCP 79. 90 Internet-Drafts are working documents of the Internet Engineering 91 Task Force (IETF). Note that other groups may also distribute 92 working documents as Internet-Drafts. The list of current Internet- 93 Drafts is at http://datatracker.ietf.org/drafts/current/. 95 Internet-Drafts are draft documents valid for a maximum of six months 96 and may be updated, replaced, or obsoleted by other documents at any 97 time. It is inappropriate to use Internet-Drafts as reference 98 material or to cite them other than as "work in progress." 100 This Internet-Draft will expire on September 22, 2015. 102 Copyright Notice 104 Copyright (c) 2015 IETF Trust and the persons identified as the 105 document authors. All rights reserved. 107 This document is subject to BCP 78 and the IETF Trust's Legal 108 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 109 license-info) in effect on the date of publication of this document. 110 Please review these documents carefully, as they describe your rights 111 and restrictions with respect to this document. Code Components 112 extracted from this document must include Simplified BSD License text 113 as described in Section 4.e of the Trust Legal Provisions and are 114 provided without warranty as described in the Simplified BSD License. 116 1. Terminology 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 2. Introduction 124 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 125 related operational practices are defined extensively [RFC1034] 126 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 127 [RFC5155]. 129 DNSSEC has now entered widespread deployment. However, domain 130 signing tools and processes are not yet as mature and reliable as is 131 the case for non-DNSSEC-related domain administration tools and 132 processes. As a result, some DNSSEC validation failures may occur. 133 When these failures do occur, end users SHOULD NOT change to a non- 134 validating DNS resolver. 136 3. Domain Validation Failures 138 A domain name can fail validation for two general reasons, a 139 legitimate security failure such as due to an attack or compromise of 140 some sort, or as a result of misconfiguration (mistake) on the part 141 of an domain administrator. There is no way for end users to discern 142 which of these issues has caused a DNSSEC-signed domain to fail 143 validation, and end users should therefore assume that it may be due 144 to a legitimate security problem. 146 4. Misunderstanding DNSSEC Validation Failures 148 End users may incorrectly interpret the failure to reach a domain due 149 to DNSSEC-related misconfiguration as their ISP or DNS resolver 150 operator purposely blocking access to the domain, or as a 151 performance-related failure on the part of their ISP. In reality, 152 these failures may be due to a security issue of which the end user 153 is not aware. 155 5. Comparison to Other DNS Misconfigurations 157 Authoritative DNS-related mistakes and errors typically affect the 158 entire Internet, and all DNS recursive resolver operators equally. 159 So for example, in an A record is incorrect, an end user would get 160 the incorrect record in a DNS response no matter what resolver they 161 used. 163 In contrast to this, DNSSEC-related mistakes, errors, or validation 164 security failures would only affect end users of validating 165 resolvers. 167 6. Switching to a Non-Validating Resolver is NOT Recommended 169 As noted in Section 4 some end users may not understand why a domain 170 fails to validate on one network but not another (or with one DNS 171 resolver but not another) Section 5. As a result, they may consider 172 switching to an alternative, non-validating resolver themselves. But 173 if a domain fails DNSSEC validation and is inaccessible, this could 174 very well be due to a security-related issue. 176 As a best practice: In order to be as safe and secure as possible, 177 end users SHOULD NOT change to DNS servers that do not perform DNSSEC 178 validation as a workaround. 180 Even if a website in a domain seems to look "normal" and valid, 181 according to the DNSSEC protocol, that domain is not secure. Domains 182 that fail DNSSEC for legitimate reasons may be in control of hackers 183 or there could be other significant security issues with the domain. 184 Thus, switching to a non-validating resolver to restore access to a 185 domain that fails DNSSEC validation is NOT recommended and is 186 potentially harmful to end user security. 188 7. Other Considerations 190 7.1. Security Considerations 192 The use of a non-validating DNS recursive resolver has comparatively 193 less security capabilities than a validating resolver, since one 194 implements DNS Security Extensions and one does not. 196 In the case of a DNSSEC validation failure, if an end user changes to 197 a non-validating resolver they may subject themselves to increased 198 security risks and threats against which DNS Security Extensions may 199 have provided protection. 201 7.2. Privacy Considerations 203 There are no privacy considerations in this document. 205 7.3. IANA Considerations 207 There are no IANA considerations in this document. 209 8. Acknowledgements 211 - William Brown 213 9. References 215 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 216 STD 13, RFC 1034, November 1987. 218 [RFC1035] Mockapetris, P., "Domain names - implementation and 219 specification", STD 13, RFC 1035, November 1987. 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. 225 Rose, "DNS Security Introduction and Requirements", RFC 226 4033, March 2005. 228 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D. and S. 229 Rose, "Resource Records for the DNS Security Extensions", 230 RFC 4034, March 2005. 232 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 233 Rose, "Protocol Modifications for the DNS Security 234 Extensions", RFC 4035, March 2005. 236 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 237 System (DNS)", RFC 4398, March 2006. 239 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 240 (DS) Resource Records (RRs)", RFC 4509, May 2006. 242 [RFC5155] Laurie, B., Sisson, G., Arends, R. and D. Blacka, "DNS 243 Security (DNSSEC) Hashed Authenticated Denial of 244 Existence", RFC 5155, March 2008. 246 [RFC5914] Housley, R., Ashmore, S. and C. Wallace, "Trust Anchor 247 Format", RFC 5914, June 2010. 249 [RFC6781] Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC 250 Operational Practices, Version 2", RFC 6781, December 251 2012. 253 Appendix A. Document Change Log 255 [RFC Editor: This section is to be removed before publication] 257 Individual-00: First version published as an individual draft. 259 Individual-01: Fixed nits identified by William Brown 261 Individual-02: Updated prior to IETF-91 263 WG-00: Renamed at request of DNSOP co-chairs 265 WG-01: Updated doc to keep it from expiring 267 Appendix B. Open Issues 269 [RFC Editor: This section is to be removed before publication] 271 Address feedback from Peter Koch, received 16 March 2015 273 Author's Address 275 Jason Livingood 276 Comcast 277 One Comcast Center 278 1701 John F. Kennedy Boulevard 279 Philadelphia, PA 19103 280 US 282 Email: jason_livingood@cable.comcast.com 283 URI: http://www.comcast.com