idnits 2.17.1 draft-livingood-dnsop-dont-switch-resolvers-02.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 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 (May 6, 2015) is 3278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 161 -- Looks like a reference, but probably isn't: '2' on line 161 == Unused Reference: 'RFC5914' is defined on line 209, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). 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 May 6, 2015 5 Expires: November 05, 2015 7 In Case of DNSSEC Validation Failures, Do Not Change Resolvers 8 draft-livingood-dnsop-dont-switch-resolvers-02 10 Abstract 12 DNS Security Extensions (DNSSEC) are being widely deployed, 13 particularly via validating resolvers. 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. As a 16 result, some DNSSEC validation failures may occur. When these 17 failures do occur, end users should not change to a non-validating 18 DNS resolver. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 05, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Domain Validation Failures . . . . . . . . . . . . . . . . . . 2 55 3. Misunderstanding DNSSEC Validation Failures . . . . . . . . . 2 56 4. Comparison to Other DNS Misconfigurations . . . . . . . . . . 2 57 5. Switching to a Non-Validating Resolver is NOT Recommended . . 3 58 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 6.1. Security Considerations . . . . . . . . . . . . . . . . . 3 60 6.2. Recommendations for Validating Resolver Operators . . . . 3 61 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 4 62 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 5 66 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 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, some DNSSEC validation failures may occur. 80 When these failures do occur, end users should not change to a non- 81 validating DNS resolver. 83 2. Domain Validation Failures 85 A domain name can fail validation for two general reasons, an actual 86 security failure such as due to an attack or compromise of some sort, 87 or as a result of misconfiguration (mistake) on the part of an domain 88 administrator. There is no way for end users to discern which of 89 these issues has caused a DNSSEC-signed domain to fail validation, 90 and end users should therefore assume that it may be due to an actual 91 security problem. 93 3. Misunderstanding DNSSEC Validation Failures 95 End users may incorrectly interpret the failure to reach a domain due 96 to DNSSEC-related misconfiguration as their ISP or DNS resolver 97 operator purposely blocking access to the domain, or as a 98 performance-related failure on the part of their ISP. In reality, 99 these failures may be due to a security issue of which the end user 100 is not aware. 102 4. Comparison to Other DNS Misconfigurations 104 Authoritative DNS-related mistakes and errors typically affect the 105 entire Internet, and all DNS recursive resolver operators equally. 106 So for example, in an A record is incorrect, an end user would get 107 the incorrect record in a DNS response no matter what resolver they 108 used. 110 In contrast to this, DNSSEC-related mistakes, errors, or validation 111 security failures would only affect end users of validating 112 resolvers. 114 5. Switching to a Non-Validating Resolver is NOT Recommended 116 As noted in Section 3 some end users may not understand why a domain 117 fails to validate on one network but not another (or with one DNS 118 resolver but not another) Section 4. As a result, they may consider 119 switching to an alternative, non-validating resolver themselves. But 120 if a domain fails DNSSEC validation and is inaccessible, this could 121 very well be due to a security-related issue. Changing to a non- 122 validating resolver is a critical security downgrade and is not well 123 advised. 125 As a recommended best practice: In order to be as safe and secure as 126 possible, end users should not change to DNS servers that do not 127 perform DNSSEC validation as a workaround. 129 Even if a website in a domain seems to look "normal" and valid, 130 according to the DNSSEC protocol, that domain is not secure. Domains 131 that fail DNSSEC validation may fail due to an actual security 132 incident or compromise, and may be in control of hackers or there 133 could be other significant security issues with the domain. Thus, 134 switching to a non-validating resolver to restore access to a domain 135 that fails DNSSEC validation is NOT recommended and is potentially 136 harmful to end user security. 138 6. Other Considerations 140 6.1. Security Considerations 142 The use of a non-validating DNS recursive resolver has comparatively 143 less security capabilities than a validating resolver, since one 144 implements DNS Security Extensions and one does not. 146 In the case of a DNSSEC validation failure, if an end user changes to 147 a non-validating resolver they may subject themselves to increased 148 security risks and threats against which DNS Security Extensions may 149 have provided protection. 151 6.2. Recommendations for Validating Resolver Operators 152 Since it is not recommended that end users change to non-validating 153 resolvers, operators of validating resolvers may wish to consider 154 what tools they might make available to their end users to assist in 155 these cases. For example, there may be a DNS looking glass that 156 enables someone to use a web page or other tool to remotely check DNS 157 resolution on the operator's servers, as well as possibly another 158 operator's servers. Such a web page or tool may also provide a link 159 to independent third party sites or tools that can confirm whether or 160 not a DNSSEC-related error is present, of which several exist today 161 (e.g. DNSViz [1], Verisign DNSSEC Debugger [2]). Finally, the 162 operator may also wish to consider a web page form or other tool to 163 enable end users to report possible DNS resolution issues. 165 6.3. Privacy Considerations 167 There are no privacy considerations in this document. 169 6.4. IANA Considerations 171 There are no IANA considerations in this document. 173 7. Acknowledgements 175 - William Brown 177 - Peter Koch 179 8. References 181 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 182 STD 13, RFC 1034, November 1987. 184 [RFC1035] Mockapetris, P., "Domain names - implementation and 185 specification", STD 13, RFC 1035, November 1987. 187 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. 188 Rose, "DNS Security Introduction and Requirements", RFC 189 4033, March 2005. 191 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D. and S. 192 Rose, "Resource Records for the DNS Security Extensions", 193 RFC 4034, March 2005. 195 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 196 Rose, "Protocol Modifications for the DNS Security 197 Extensions", RFC 4035, March 2005. 199 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 200 System (DNS)", RFC 4398, March 2006. 202 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 203 (DS) Resource Records (RRs)", RFC 4509, May 2006. 205 [RFC5155] Laurie, B., Sisson, G., Arends, R. and D. Blacka, "DNS 206 Security (DNSSEC) Hashed Authenticated Denial of 207 Existence", RFC 5155, March 2008. 209 [RFC5914] Housley, R., Ashmore, S. and C. Wallace, "Trust Anchor 210 Format", RFC 5914, June 2010. 212 [RFC6781] Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC 213 Operational Practices, Version 2", RFC 6781, December 214 2012. 216 Appendix A. Document Change Log 218 [RFC Editor: This section is to be removed before publication] 220 Individual-00: First version published as an individual draft. 222 Individual-01: Fixed nits identified by William Brown 224 Individual-02: Updated prior to IETF-91 226 WG-00: Renamed at request of DNSOP co-chairs 228 WG-01: Updated doc to keep it from expiring 230 WG-02: Addressed some feedback from Peter Koch on RFC 2119 text, 231 changed from BCP to Informational since this is more a recommended 232 practice, added a section with recommendations for operators. 234 Appendix B. Open Issues 236 [RFC Editor: This section is to be removed before publication] 238 Author's Address 240 Jason Livingood 241 Comcast 242 One Comcast Center 243 1701 John F. Kennedy Boulevard 244 Philadelphia, PA 19103 245 US 247 Email: jason_livingood@cable.comcast.com 248 URI: http://www.comcast.com