idnits 2.17.1 draft-livingood-dnsop-dont-switch-resolvers-05.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 91: '...ailures do occur, end users SHOULD NOT...' RFC 2119 keyword, line 108: '...mmend that users SHOULD NOT change DNS...' RFC 2119 keyword, line 186: '...sible, end users SHOULD NOT change to ...' RFC 2119 keyword, line 238: '...otect their security, users SHOULD NOT...' RFC 2119 keyword, line 252: '...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 (August 13, 2019) is 1716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 327 -- Looks like a reference, but probably isn't: '2' on line 329 == Unused Reference: 'RFC5914' is defined on line 307, 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 August 13, 2019 5 Expires: February 14, 2020 7 In Case of DNSSEC Validation Failures, Do Not Change Resolvers 8 draft-livingood-dnsop-dont-switch-resolvers-05 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. When these failures do 18 occur, end users should not change to a non-validating DNS resolver, 19 as that would downgrade their security. They should instead wait 20 until the authoritative domain operator updates their DNS records to 21 resolve the error and that change propagates across the Internet's 22 DNS resolvers, the timing of which may be dependent upon the Time To 23 Live (TTL) settings in the old and/or erroneous DNS resource records. 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 February 14, 2020. 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. Reasons for DNSSEC Validation Failure . . . . . . . . . . . . 3 61 3. Misunderstanding DNSSEC Validation Failures . . . . . . . . . 3 62 4. Comparison to Other DNS Misconfigurations . . . . . . . . . . 4 63 5. Switching to a Non-Validating Resolver is NOT Recommended . . 4 64 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Recommendations for Validating Resolver Operators . . . . 5 66 6.2. Security Considerations . . . . . . . . . . . . . . . . . 5 67 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 6 68 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 8 74 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 80 related operational practices are defined extensively [RFC1034] 81 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 82 [RFC5155]. 84 DNS Security Extensions (DNSSEC) validation by recursive DNS 85 resolvers has been deployed at scale. However, domain signing tools 86 and processes are not yet as mature and reliable as is the case for 87 non-DNSSEC-related domain administration tools and processes. This 88 sometimes results in DNSSEC validation failures, for which operators 89 of validating resolvers are often blamed. 91 When these DNSSEC validation failures do occur, end users SHOULD NOT 92 change to a non-validating DNS resolver, as that would downgrade 93 their security. They should instead wait until the authoritative 94 domain operator updates their DNS records to resolve the error and 95 then for that change to propagate across the Internet's DNS 96 resolvers, the timing of which may be dependent upon the Time To Live 97 (TTL) settings in the old and/or erroneous DNS resource records. 99 This document is necessary because it has become commonplace for 100 reporters, technical users, and others to recommend that people 101 change to non-validating resolvers when a DNSSEC validation failure 102 occurs. This is NOT a recommended practice, it actively downgrades 103 user security, and it reduces the incentives for authoritative domain 104 operators to improve their DNSSEC-related domain administration tools 105 and processes. 107 As a result, this document provides an authoritative reference point 108 to recommend that users SHOULD NOT change DNS resolvers when DNSSEC 109 validation failures occur. Such errors may be due to genuine 110 security problems, which DNSSEC validation was designed to protect 111 against. In the same way that a Transport Layer Security (TLS) 112 [RFC8446] certificate failure should not be bypassed or ignored, so 113 too that DNSSEC validation failures should not be bypassed or 114 ignored. 116 2. Reasons for DNSSEC Validation Failure 118 A domain name can fail DNSSEC validation for two general reasons: an 119 actual security failure such as due to an attack or compromise of 120 some sort, or as a result of misconfiguration (mistake) on the part 121 of a domain administrator. There is no way for an average end user 122 to discern which of these issues has caused a DNSSEC-signed domain to 123 fail validation, and so end users should therefore assume that it is 124 due to an actual security problem as the most conservative and 125 security-protective approach. 127 3. Misunderstanding DNSSEC Validation Failures 129 End users may incorrectly interpret the failure to reach a domain due 130 to DNSSEC-related misconfiguration as their ISP or DNS resolver 131 operator purposely blocking access to the domain, or as a 132 performance-related failure on the part of that ISP or DNS resolver 133 operator. In reality, these failures may be due to a security issue 134 of which the end user is not aware. If a user ignores such a 135 failure, or is instructed to ignore it, and switches to a non- 136 validating resolver, they may be subject to the risk of malware 137 exposure, phishing attack, and so on. The root cause of a DNSSEC 138 validation failure lies not with a recursive DNS operator but with 139 the authoritative domain name owner or administrator [I-D.draft- 140 livingood-dnsop-auth-dnssec-mistakes] . 142 4. Comparison to Other DNS Misconfigurations 144 Authoritative DNS-related mistakes and errors typically affect the 145 entire Internet, and all DNS recursive resolver operators equally. 146 So for example, in an A record is incorrect, an end user would get 147 the incorrect record in a DNS response no matter what resolver they 148 used. 150 In contrast to this, DNSSEC-related mistakes, errors, or other 151 validation security failures would only affect end users of those 152 validating resolvers. That being said, different validating resolver 153 operators may configure their servers slightly differently, have 154 different server software, or have different server configurations, 155 which can result in slightly different resolver validation behavior. 156 It can also be the case that one resolver has cached a DNS resource 157 record according to the TTL set by the authoritative domain 158 administrator, while another resolver does not have that record 159 cached (generally due to the timing of prior user queries for that 160 name), which can also cause two resolvers to differ. Another reason 161 for resolution variance may be that the authoritative DNS servers are 162 responding differently to various DNS resolvers, perhaps to 163 geographic differences, the nature of any delegations to Content 164 Delivery Networks (CDNs), a regionally-focused Denial of Service 165 (DoS) attack against an authoritative server, or a wide range of 166 other potential reasons. 168 5. Switching to a Non-Validating Resolver is NOT Recommended 170 As noted in Section 3 some end users may not understand why a domain 171 fails to validate on one network but not another (or with one DNS 172 resolver but not another) Section 4. As a result, they may consider 173 or someone may recommend to them switching to an alternative, non- 174 validating resolver themselves. But if a domain fails DNSSEC 175 validation and is inaccessible, this could very well be due to a 176 security-related issue. Changing to a non-validating resolver is a 177 critical security downgrade and is NOT advised. 179 DNSSEC validation failures may be due to genuine security problems, 180 which DNSSEC validation was designed to protect against. In the same 181 way that a Transport Layer Security (TLS) [RFC8446] certificate 182 failure should not be bypassed or ignored, so too that DNSSEC 183 validation failures should not be bypassed or ignored. 185 As a recommended best practice: In order to be as safe and secure as 186 possible, end users SHOULD NOT change to DNS resolvers that do not 187 perform DNSSEC validation as a workaround when DNSSEC validation 188 failures occur. 190 Even if a website in a domain seems to look "normal" and valid, 191 according to the DNSSEC protocol, that domain is not secure. Domains 192 that fail DNSSEC validation may fail due to an actual security 193 incident or compromise, and may be in control of hackers or there 194 could be other significant security issues with the domain. Thus, 195 switching to a non-validating resolver to restore access to a domain 196 that fails DNSSEC validation is NOT recommended and is potentially 197 harmful to end user security. 199 6. Other Considerations 201 6.1. Recommendations for Validating Resolver Operators 203 Since it is not recommended that end users change to non-validating 204 resolvers, operators of validating resolvers may wish to consider 205 what tools they might make available to their end users to assist in 206 these cases. For example, there may be a DNS looking glass that 207 enables someone to use a web page or other tool to remotely 208 (including from a different network) check DNS resolution on the 209 operator's servers, as well as possibly another operator's servers. 210 Such a web page or tool may also provide a link to independent third 211 party sites or tools that can confirm whether or not a DNSSEC-related 212 error is present, of which several exist today (e.g. DNSViz [1], 213 Verisign DNSSEC Debugger [2]). Finally, the operator may also wish 214 to consider a web page form or other tool to enable end users to 215 report possible DNS resolution issues. 217 Resolver operators may also find it helpful to selectively use a 218 Negative Trust Anchor [RFC7646] to temporarily mitigate validation 219 failures that are absolutely confirmed to be due to authoritative 220 domain name administration error by that administrator. In addition, 221 in select cases such as a very high traffic domain name, once an 222 administrative DNS error or problem has been fixed a resolver may 223 consider clearing the cache of their recursive resolvers in order to 224 pickup the authoritative change immediately (rather than waiting 225 until the TTL on a cached record expires). 227 6.2. Security Considerations 229 The use of a non-validating DNS recursive resolver is comparatively 230 less secure than using a validating resolver, since one implements 231 DNS Security Extensions (DNSSEC) and one does not. 233 In the case of a DNSSEC validation failure, if an end user changes to 234 a non-validating resolver they can subject themselves to increased 235 security risks and threats against which DNSSEC may have provided 236 protection. 238 As a result, in order to protect their security, users SHOULD NOT 239 switch to a non-validating resolver when a DNSSEC validation failure 240 occurs. 242 6.3. Privacy Considerations 244 In the case of a DNSSEC validation failure, if an end user changes to 245 a non-validating resolver they can subject themselves to increased 246 security risks and threats against which DNSSEC may have provided 247 protection. This can include threats to their privacy, such as by 248 unwittingly visiting a phishing site and sharing sensitive data or 249 other private information with a malicious party or some party other 250 than that which was originally intended. 252 As a result, in order to protect their privacy, users SHOULD NOT 253 switch to a non-validating resolver when a DNSSEC validation failure 254 occurs. 256 6.4. IANA Considerations 258 There are no IANA considerations in this document. 260 7. Acknowledgements 262 - William Brown 264 - Peter Koch 266 8. References 268 8.1. Normative References 270 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 271 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 272 . 274 [RFC1035] Mockapetris, P., "Domain names - implementation and 275 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 276 November 1987, . 278 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 279 Rose, "DNS Security Introduction and Requirements", 280 RFC 4033, DOI 10.17487/RFC4033, March 2005, 281 . 283 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "Resource Records for the DNS Security Extensions", 285 RFC 4034, DOI 10.17487/RFC4034, March 2005, 286 . 288 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 289 Rose, "Protocol Modifications for the DNS Security 290 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 291 . 293 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 294 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 295 . 297 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 298 (DS) Resource Records (RRs)", RFC 4509, 299 DOI 10.17487/RFC4509, May 2006, 300 . 302 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 303 Security (DNSSEC) Hashed Authenticated Denial of 304 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 305 . 307 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 308 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 309 . 311 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 312 Operational Practices, Version 2", RFC 6781, 313 DOI 10.17487/RFC6781, December 2012, 314 . 316 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 317 and R. Weber, "Definition and Use of DNSSEC Negative Trust 318 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 319 . 321 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 322 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 323 . 325 8.2. URIs 327 [1] http://dnsviz.net/ 329 [2] http://dnssec-debugger.verisignlabs.com/ 331 Appendix A. Document Change Log 333 [RFC Editor: This section is to be removed before publication] 335 Individual-00: First version published as an individual draft. 337 Individual-01: Fixed nits identified by William Brown 339 Individual-02: Updated prior to IETF-91 341 WG-00: Renamed at request of DNSOP co-chairs 343 WG-01: Updated doc to keep it from expiring 345 WG-02: Addressed some feedback from Peter Koch on RFC 2119 text, 346 changed from BCP to Informational since this is more a recommended 347 practice, added a section with recommendations for operators. 349 WG-03 to 04: Refreshed document 351 WG-05: Refreshed to buy time for me to write a combined document 353 Appendix B. Open Issues 355 [RFC Editor: This section is to be removed before publication] 357 Fix I-D xref 359 Author's Address 361 Jason Livingood 362 Comcast 364 Email: jason_livingood@comcast.com