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