idnits 2.17.1 draft-livingood-negative-trust-anchors-07.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 336: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 337: '... less. Implementors SHOULD set an end...' RFC 2119 keyword, line 339: '... Implementors SHOULD in most cases l...' RFC 2119 keyword, line 655: '...endation that it SHOULD generally be l...' RFC 2119 keyword, line 704: '...es NTA and what tests MUST pass before...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2014) is 3474 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 C. Griffiths 5 Expires: March 28, 2015 Dyn 6 September 24, 2014 8 Definition and Use of DNSSEC Negative Trust Anchors 9 draft-livingood-negative-trust-anchors-07 11 Abstract 13 DNS Security Extensions (DNSSEC) is now entering widespread 14 deployment. However, domain signing tools and processes are not yet 15 as mature and reliable as is the case for non-DNSSEC-related domain 16 administration tools and processes. One potential technique to 17 mitigate this is to use a Negative Trust Anchor, which is defined in 18 this document. 20 This document discusses Trust Anchors for DNSSEC and defines a 21 Negative Trust Anchor, which is potentially useful during the 22 transition to ubiquitous DNSSEC deployment. These are configured 23 locally on a particular instance of a validating DNS recursive 24 resolver and can shield end users of such a resolver from the DNSSEC- 25 related authoritative name server operational errors that appear to 26 be somewhat typical during the transition to ubiquitous DNSSEC 27 deployment. Negative Trust Anchors are intended to be temporary, and 28 should not be distributed by IANA or any other organization outside 29 of the administrative boundary of the organization locally 30 implementing a Negative Trust Anchor. Finally, Negative Trust 31 Anchors pertain only to DNSSEC and not to Public Key Infrastructures 32 (PKI) such ad X.509. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 28, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 4 69 3. Limited Time and Scope of Use . . . . . . . . . . . . . . . . 4 70 4. Domain Validation Failures . . . . . . . . . . . . . . . . . 5 71 5. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 5 72 6. Switching to a Non-Validating Resolver is Not Recommended . . 6 73 7. Responsibility for Failures . . . . . . . . . . . . . . . . . 6 74 8. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 7 75 9. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 8 76 10. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 9 77 11. Comparison to Other DNS Misconfigurations . . . . . . . . . . 9 78 12. Intentionally Broken Domains . . . . . . . . . . . . . . . . 10 79 13. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 80 13.1. Security Considerations . . . . . . . . . . . . . . . . 10 81 13.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11 82 13.3. IANA Considerations . . . . . . . . . . . . . . . . . . 11 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 15.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 13 88 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 94 related operational practices are defined extensively [RFC1034] 96 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 97 [RFC5155]. 99 This document discusses Trust Anchors for DNSSEC and defines a 100 Negative Trust Anchor, which is potentially useful during the 101 transition to ubiquitous DNSSEC deployment. These are configured 102 locally on a particular instance of a validating DNS recursive 103 resolver and can shield end users of such a resolver from the DNSSEC- 104 related authoritative name server operational errors that appear to 105 be somewhat typical during the transition to ubiquitous DNSSEC 106 deployment. Negative Trust Anchors are intended to be temporary, and 107 should not be distributed by IANA or any other organization outside 108 of the administrative boundary of the organization locally 109 implementing a Negative Trust Anchor. Finally, Negative Trust 110 Anchors pertain only to DNSSEC and not to Public Key Infrastructures 111 (PKI) such ad X.509. [REFERENCE NECESSARY?] 113 DNSSEC has now entered widespread deployment. However, domain 114 signing tools and processes are not yet as mature and reliable as is 115 the case for non-DNSSEC-related domain administration tools and 116 processes. As a result, operators of DNS recursive resolvers, such 117 as Internet Service Providers (ISPs), occasionally observe domains 118 incorrectly managing DNSSEC-related resource records. This 119 mismanagement triggers DNSSEC validation failures, and then causes 120 large numbers of end users to be unable to reach a domain. Many end 121 users tend interpret this as a failure of their DNS servers, and may 122 switch to a non-validating resolver or contact their ISP to complain, 123 rather than seeing this as a failure on the part of the domain they 124 wanted to reach. 126 In the short-term, one potential way to address this is for DNS 127 operators to use a Negative Trust Anchor to temporarily disable 128 DNSSEC validation for a specific misconfigured domain name. This 129 immediately restores access for end users while that domain's 130 administrators fix their misconfiguration. While DNS operators 131 likely prefer not to use this tool, during the global transition to 132 DNSSEC it seems some tool is needed to reduce the negative impact on 133 such operators. 135 A Negative Trust Anchor should be considered a transitional and 136 temporary tactic which is not particularly scalable and should not be 137 used in the long-term. Over time, however, the use of Negative Trust 138 Anchors will become less necessary as DNSSEC-related domain 139 administration becomes more resilient. 141 2. Definition of a Negative Trust Anchor 143 Trust Anchors are defined in [RFC5914]. A trust anchor should be 144 used by a validating caching resolver as a starting point for 145 building the authentication chain for a signed DNS response. The 146 inverse of this is a Negative Trust Anchor, which creates a stopping 147 point for a caching resolver to end validation of the authentication 148 chain. This Negative Trust Anchor can potentially be placed at any 149 level within the chain of trust and would stop validation at that 150 point in the chain. 152 3. Limited Time and Scope of Use 154 As noted in Section 1, the use of Negative Trust Anchors should be 155 temporary. These are key recommendations pertaining to this 156 practice: 158 1. The general practice of using Negative Trust Anchors should be 159 limited to the transition to widespread deployment of DNSSEC 160 (including signing of domain names and validation in DNS 161 recursive resolvers). Thus, the practice of using Negative Trust 162 Anchors should not be permanent. 164 2. During this transition phase when Negative Trust Anchors may be 165 useful, the use of a particular Negative Trust Anchor should be 166 temporary and in most cases limited to no more than 1 day. Thus, 167 the use of an individual Negative Trust Anchor should be strictly 168 time limited and very short in duration. 170 3. So that the use of Negative Trust Anchors remains temporary and 171 useful only during a transition to widespread DNSSEC deployment, 172 the use and distribution of individual Negative Trust Anchors 173 should not be centralized, beyond the borders of one 174 organization's operational unit. Thus, no organization should 175 endeavor to create and centrally distribute Negative Trust 176 Anchors to other organizations as was the case with positive 177 Trust Anchors prior to the signing of the root. 179 4. As noted in Section 12, organizations that utilize Negative Trust 180 Anchors should not add a Negative Trust Anchor for any 181 intentionally broken domain. 183 5. As noted in Section 8, use of a Negative Trust Anchor should not 184 be automatic in any way, and must involve investigation by 185 technical personnel trained in the operation of DNS servers. 187 4. Domain Validation Failures 189 A domain name can fail validation for two general reasons, a 190 legitimate security failure such as due to an attack or compromise of 191 some sort, or as a result of misconfiguration on the part of an 192 domain administrator. As domains transition to DNSSEC the most 193 likely reason for a validation failure will be due to 194 misconfiguration. Thus, domain administrators should be sure to read 195 [RFC6781] in full. They should also pay special attention to 196 Section 4.2, pertaining to key rollovers, which appears to be the 197 cause of many recent validation failures. 199 In one recent example [DNSSEC-Validation-Failure-Analysis], a 200 specific domain name failed to validate. An investigation revealed 201 that the domain's administrators performed a Key Signing Key (KSK) 202 rollover by (1) generating a new key and (2) signing the domain with 203 the new key. However, they did not use a double-signing procedure 204 for the KSK and a pre-publish procedure for the ZSK. Double-signing 205 refers to signing a zone with two KSKs and then updating the parent 206 zone with the new DS record so that both keys are valid at the same 207 time. This meant that the domain name was signed with the new KSK, 208 but it was not double-signed with the old KSK. So, the new key was 209 used for signing the zone but the old key was not. As a result, the 210 domain could not be trusted and returned an error when trying to 211 reach the domain. Thus, the domain was in a situation where the 212 DNSSEC chain of trust was broken because the Delegation Signer (DS) 213 record pointed to the old KSK, which was no longer used for signing 214 the zone. (A DS record provides a link in the chain of trust for 215 DNSSEC from the parent zone to the child zone - in this case between 216 TLD and domain name.) 218 In addition, it is possible that some DNSSEC validation failures 219 could arise due to differences in how different software developers 220 interpret DNSSEC standards and/or how those developers choose to 221 implement support for DNSSEC. For example, it is conceivable that 222 some domain may be DNSSEC signed properly, and Unbound-based DNS 223 recursive resolvers will validate the domain but those using BIND or 224 Nominum's Vantio software may fail to validate a domain. 226 5. End User Reaction 228 End users generally do not know what DNSSEC is, nor should they be 229 expected to at the current time (especially absent widespread 230 integration of DNSSEC indicators in end user software such as web 231 browsers). As a result, end users may incorrectly interpret the 232 failure to reach a domain due to DNSSEC-related misconfiguration as 233 their ISP purposely blocking access to the domain or as a performance 234 failure on the part of their ISP (especially of the ISP's DNS 235 servers). End users may feel less satisfied with their ISP's 236 service, which may make them more likely to switch to a competing 237 ISP. They may also contact their ISP to complain, which of course 238 will incur cost for their ISP. In addition, they may use online 239 tools and sites to complain of this problem, such as via a blog, web 240 forum, or social media site, which may lead to dissatisfaction on the 241 part of other end users or general criticism of an ISP or operator of 242 a DNS recursive resolver. 244 As end users publicize these failures, others may recommend they 245 switch from security-aware DNS resolvers to resolvers not performing 246 DNSSEC validation. This is a shame since the ISP or other DNS 247 recursive resolver operator is actually doing exactly what they are 248 supposed to do in failing to resolve a domain name, as this is the 249 expected result when a domain can no longer be validated, protecting 250 end users from a potential security threat. 252 6. Switching to a Non-Validating Resolver is Not Recommended 254 As noted in Section 5 some people may consider switching to an 255 alternative, non-validating resolver themselves, or may recommend 256 that others do so. But if a domain fails DNSSEC validation and is 257 inaccessible, this could very well be due to a security-related 258 issue. In order to be as safe and secure as possible, end users 259 should not change to DNS servers that do not perform DNSSEC 260 validation as a workaround, and people should not recommend that 261 others do so either. Even if a website in a domain seems to look 262 "normal" and valid, according to the DNSSEC protocol, that domain is 263 not secure. Domains that fail DNSSEC for legitimate reasons may be 264 in control of hackers or there could be other significant security 265 issues with the domain. 267 Thus, switching to a non-validating resolver to restore access to a 268 domain that fails DNSSEC validation is not a recommended practice, is 269 bad advice to others, is potentially harmful to end user security, 270 and is potentially harmful to DNSSEC adoption. 272 7. Responsibility for Failures 274 A domain administrator is solely and completely responsible for 275 managing their domain name(s) and DNS resource records. This 276 includes complete responsibility for the correctness of those 277 resource records, the proper functioning of their DNS authoritative 278 servers, and the correctness of DNS records linking their domain to a 279 top-level domain (TLD) or other higher level domain. Even in cases 280 where some error may be introduced by a third party, whether that is 281 due to an authoritative server software vendor, software tools 282 vendor, domain name registrar, or other organization, these are all 283 parties that the domain administrator has selected and is responsible 284 for managing successfully. 286 There are some cases where the domain administrator is different than 287 the domain owner. In those cases, a domain owner has delegated 288 operational responsibility to the domain administrator. So no matter 289 whether a domain owner is also the domain administrator or not, the 290 domain administrator is nevertheless operationally responsible for 291 the proper configuration operation of the domain. 293 So in the case of a domain name failing to successfully validate, 294 when this is due to a misconfiguration of the domain, that is the 295 sole responsibility of the domain administrator. 297 Any assistance or mitigation responses undertaken by other parties to 298 mitigate the misconfiguration of a domain name by a domain 299 administrator, especially operators of DNS recursive resolvers, are 300 optional and at the pleasure of those parties. 302 8. Use of a Negative Trust Anchor 304 When a domain has been confirmed to fail DNSSEC validation due to a 305 DNSSEC-related misconfiguration, an ISP or other DNS recursive 306 resolver operator may in some cases use a Negative Trust Anchor for a 307 domain or sub-domain. This instructs a DNS recursive resolver to 308 temporarily NOT perform DNSSEC validation for a specific domain name. 309 This immediately restores access to the domain for end users while 310 the domain's administrator corrects the misconfiguration(s). 312 In the case of a validation failure due to misconfiguration of a TLD 313 or popular domain name (such as a top 100 website), this could make 314 content or services in the affected TLD or domain to be inaccessible 315 for a large number of users. A Negative Trust Anchor can therefore 316 be useful in the short-term when used on a targeted and time-limited 317 basis. It does not and should not involve turning off validation 318 more broadly, and helps during the transition to DNSSEC as 319 organizations that are new to signing their domains are still 320 maturing their DNSSEC operational practices, alleviating end user 321 issues as noted in Section 5 and restoring end user access. However, 322 use of a Negative Trust Anchor should not be automatic in any way, 323 and must involve investigation by technical personnel trained in the 324 operation of DNS servers. 326 Technical personnel should also confirm that the domain is not 327 intentionally broken, such as for testing purposes as noted in 328 Section 12. Such an investigation must confirm that a failure is due 329 to misconfiguration, as a similar breakage could have occurred if an 330 attacker gained access to a domain's authoritative servers and 331 modified those records or had the domain pointed to their own rogue 332 authoritative servers. In addition, personnel should make a 333 reasonable attempt to contact a domain for which a Negative Trust 334 Anchor may be used, and preferably prior to implementing it. 336 Furthermore, a Negative Trust Anchor MUST only be used for a short 337 duration, such as for a day or less. Implementors SHOULD set an end 338 time and date associated with any Negative Trust Anchor. 339 Implementors SHOULD in most cases limit the maximum duration to one 340 day, meaning the Negative Trust Anchor will be removed or invalidated 341 from the point of implementation, plus 86,400 seconds. However, 342 there may be corner cases where a Negative Trust Anchor is needed for 343 a longer period of time. Optimally this time and date is set in a 344 DNS recursive resolver's configuration, though in the short-term this 345 may also be achieved via other systems or supporting processes. 347 Finally, a Negative Trust Anchor is used only in a specific domain or 348 sub-domain and would not affect validation at other names up the 349 authentication chain. For example, a Negative Trust Anchor for 350 zone1.example.com would affect only names within zone1.example.com, 351 and validation would still be performed on example.com, .com, and the 352 root ("."). In another example, a Negative Trust Anchor for 353 example.com would affect only names within example.com, and 354 validation would still be performed on .com, and the root (".") 356 Root (.) <====== 357 | || 358 | ||<======>+----+----+ DNSSEC 359 | || |Recursive| Validation 360 TLD (com) <=====|| |Resolver | <==============> 361 | +<------>+---------+ 362 | | DNS NTA 363 | | (zone1.example.com) 364 SUB TLD (example.com) <------| <--------------> 365 | | 366 | | 367 | | 368 (zone1.example.com <-----| 370 Figure 1: Negative Trust Anchor Diagram 372 9. Managing Negative Trust Anchors 374 This tool is unlikely to be and probably should not be used over the 375 long-term since DNSSEC-related domain administration practices will 376 naturally improve over time. In addition, however, continued and 377 frequent use of Negative Trust Anchors is not scalable since it 378 requires investigation by technical personnel and may involve manual 379 processes, resulting in increased operational overhead (and therefore 380 cost). 382 While Negative Trust Anchors have proven useful during the early 383 stages of DNSSEC adoption, domain owners are ultimately responsible 384 for managing and ensuring their DNS records are configured correctly 385 Section 7. 387 Most current implementations of DNS validating resolvers currently 388 follow [RFC4033] on defining the implementation of Trust Anchor as 389 either using Delegation Signer (DS), Key Signing Key (KSK), or Zone 390 Signing Key (ZSK). A Negative Trust Anchor should use domain name 391 formatting that signifies where in a delegation a validation process 392 should be stopped. 394 Different DNS recursive resolvers may have different configuration 395 names for a Negative Trust Anchor. For example, Unbound calls their 396 configuration "domain-insecure" [Unbound-Configuration] 398 10. Removal of a Negative Trust Anchor 400 As explored in Section 13.1, if a Negative Trust Anchor is still in 401 place after the point in time when the DNS misconfiguration that 402 caused validation to break has been fixed, this could be problematic. 403 It is therefore recommended that implementors should periodically or 404 even continuously attempt to validate the domain in question, for the 405 period of time that the Negative Trust Anchor is in place, until such 406 validation is again successful. (Obviously a Negative Trust Anchor 407 could be removed prior to validation succeeding again, alleviating an 408 implementor of the need to continuing to test validation separate 409 from their normal operations.) 411 Once validation is again successful, a Negative Trust Anchor should 412 be removed as soon as is reasonably possible. Optimally this is 413 automatic, though it may also be achieved via other systems or 414 supporting processes. 416 11. Comparison to Other DNS Misconfigurations 418 As noted in Section 7 domain administrators are ultimately 419 responsible for managing and ensuring their DNS records are 420 configured correctly. ISPs or other DNS recursive resolver operators 421 cannot and should not correct misconfigured A, CNAME, MX, or other 422 resource records of domains for which they are not authoritative. 423 Expecting non-authoritative entities to protect domain administrators 424 from any misconfiguration of resource records is therefore 425 unrealistic and unreasonable, and in the long-term is harmful to the 426 delegated design of the DNS and could lead to extensive operational 427 instability and/or variation. 429 12. Intentionally Broken Domains 431 Some domains, such as dnssec-failed.org, have been intentionally 432 broken for testing purposes 433 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 434 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 435 If an end user is querying a validating DNS recursive resolver, then 436 this or other similarly intentionally broken domains should fail to 437 resolve and should result in a SERVFAIL error. If such a domain 438 resolved successfully, then it is a sign that the DNS recursive 439 resolver is not fully validating. 441 Organizations that utilize Negative Trust Anchors should not add a 442 Negative Trust Anchor for any intentionally broken domain. 444 Organizations operating an intentionally broken domain may wish to 445 consider adding a TXT record for the domain to the effect of "This 446 domain is purposely DNSSEC broken for testing purposes". 448 13. Other Considerations 450 13.1. Security Considerations 452 End to end DNSSEC validation will be disabled during the time that a 453 Negative Trust Anchor is used. In addition, the Negative Trust 454 Anchor may be in place after the point in time when the DNS 455 misconfiguration that caused validation to break has been fixed. 456 Thus, there may be a gap between when a domain has have been re- 457 secured and when a Negative Trust Anchor is removed. In addition, a 458 Negative Trust Anchor may be put in place by DNS recursive resolver 459 operators without the knowledge of the authoritative domain 460 administrator for a given domain name. 462 End users of a DNS recursive resolver or other people may wonder why 463 a domain that fails DNSSEC validation resolves with a supposedly 464 validating resolver. As a result, implementors should consider 465 transparently disclosing those Negative Trust Anchors which are 466 currently in place or were in place in the past, such as on a website 467 [Disclosure-Example]. This is particularly important since there is 468 currently no special DNS query response code that could indicate to 469 end users or applications that a Negative Trust Anchor is in place. 470 Such disclosures should optimally include both the data and time that 471 the Negative Trust Anchor was put in place and when it was removed. 473 13.2. Privacy Considerations 475 There are no privacy considerations in this document. 477 13.3. IANA Considerations 479 There are no IANA considerations in this document. 481 14. Acknowledgements 483 Several people made contributions of text to this document and/or 484 played an important role in the development and evolution of this 485 document. This in some cases included performing a detailed review 486 of this document and then providing feedback and constructive 487 criticism for future revisions, or engaging in a healthy debate over 488 the subject of the document. All of this was helpful and therefore 489 the following individuals merit acknowledgement: 491 - Joe Abley 493 - John Barnitz 495 - Tom Creighton 497 - Marco Davids 499 - Brian Dickson 501 - Patrik Falstrom 503 - Tony Finch 505 - Chris Ganster 507 - Olafur Gudmundsson 509 - Peter Hagopian 511 - Wes Hardaker 513 - Paul Hoffman 515 - Shane Kerr 517 - Murray Kucherawy 519 - Warren Kumari 520 - Rick Lamb 522 - Marc Lampo 524 - Ted Lemon 526 - Ed Lewis 528 - Antoin Verschuren 530 - Paul Vixie 532 - Patrik Wallstrom 534 - Nick Weaver 536 - Ralf Weber 538 15. References 540 15.1. Normative References 542 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 543 STD 13, RFC 1034, November 1987. 545 [RFC1035] Mockapetris, P., "Domain names - implementation and 546 specification", STD 13, RFC 1035, November 1987. 548 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 549 Rose, "DNS Security Introduction and Requirements", RFC 550 4033, March 2005. 552 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 553 Rose, "Resource Records for the DNS Security Extensions", 554 RFC 4034, March 2005. 556 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 557 Rose, "Protocol Modifications for the DNS Security 558 Extensions", RFC 4035, March 2005. 560 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 561 System (DNS)", RFC 4398, March 2006. 563 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 564 (DS) Resource Records (RRs)", RFC 4509, May 2006. 566 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 567 Security (DNSSEC) Hashed Authenticated Denial of 568 Existence", RFC 5155, March 2008. 570 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 571 Format", RFC 5914, June 2010. 573 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 574 Operational Practices, Version 2", RFC 6781, December 575 2012. 577 15.2. Informative References 579 [DNSSEC-Validation-Failure-Analysis] 580 Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., 581 and J. Livingood, "Analysis of DNSSEC Validation Failure - 582 NASA.GOV", Comcast , January 2012, 583 . 586 [Disclosure-Example] 587 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 588 Comcast , February 2013, 589 . 592 [Measuring-DNSSEC-Validation-of-Website-Visitors] 593 Mens, J., "Is my Web site being used via a DNSSEC- 594 validator?", July 2012, . 597 [Netalyzr] 598 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 599 "Implications of Netalyzr's DNS Measurements", Securing 600 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 601 2011, . 604 [Unbound-Configuration] 605 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 606 2010, . 609 Appendix A. Document Change Log 611 [RFC Editor: This section is to be removed before publication] 613 -00: First version published as an individual draft. 615 -01: Fixed minor typos and grammatical nits. Closed all open 616 editorial items. 618 -02: Simple date change to keep doc from expiring. Substantive 619 updates planned. 621 -03: Changes to address feedback from Paul Vixie, by adding a new 622 section "Limited Time and Scope of Use". Changes to address issues 623 raised by Antoin Verschuren and Patrik Wallstrom, by adding a new 624 section "Intentionally Broken Domains" and added two related 625 references. Added text to address the need for manual investigation, 626 as suggested by Patrik Falstrom. Added a suggestion on notification 627 as suggested by Marc Lampo. Made several additions and changes 628 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 629 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 631 -04: Moved the section defining a NTA forward, and added new text to 632 the Abstract and Introduction per feedback from Paul Hoffman. 634 -05: Incorporated feedback from the DNSOP WG list received on 2/17/13 635 and 2/18/13. This is likely the final version before the IETF 86 636 draft cutoff date. Updated references to RFC6781 to RFC6781, per 637 March Davids. 639 -06: Added more OPEN issues to continue tracking WG discussion. No 640 changes in the main document - just expanded issue tracking. 642 -07: Refresh document - needs revision and rework before IETF-91. 643 Planning to add more contributors. 645 Appendix B. Open Issues 647 [RFC Editor: This section is to be removed before publication] 649 Determine whether RFC 2119 language should be used or not when 650 describing things like the duration of a NTA. 652 The DNSOP WG should discuss whether a 1 day limit is reasonable, 653 whether a different time (more or less than 1 day, such as 1 hour or 654 1 week) should be specified, or whether no time should be specified 655 (just a recommendation that it SHOULD generally be limited to X). 657 Olafur Gudmundsson has suggested that we may want to consider whether 658 a non validatable RRSIG should be returned or not when a NTA is in 659 place. This was raised in the context of NLnet Labs' DNSSEC-Trigger, 660 which apparently acts like forwarding stub-validator. He said, "The 661 reason for this is if NTA strips signatures the stub-validator thinks 662 it is under attack and may a) go into recursive mode to try to 663 resolve the domain, getting to the right answer the long way. b) Give 664 the wrong error "Missing signatures" instead of the real error. If 665 all the validator does is not to set the AD bit for RRsets at and 666 below the NTA, stub-resolvers (and cascading resolvers) should be 667 happy." 669 Determine whether an informative reference to X.509 in the 670 Introduction is necessary. 672 Is it desirable to say that NTAs should not be distributed across 673 organizational boundaries? 675 Per Warren Kumari on 2/19/2013, add examples to appendix. "it would 676 be very helpful to actually show how this is used, with e.g and 677 example in an Appendix, for -insert favorite resolver here-. The 678 document contains a lot of really useful content about why you might 679 use one, how to minimize damage, etc but (IMO) does't do a great job 680 of explaining how to actually do so". Rick Lamb and Joe Abley also 681 agreed on the need for this. 683 Per Rick Lamb on 2/20/2013, "it might be useful to have section 2 684 "Definition .." make that clear for slow people like me - that the 685 NTA is not an RR and is more of a configuration. Maybe simply 686 replacing "placed" with "implemented" in section 2? "This NTA can 687 potentially be -placed/implemented- at any level within the chain of 688 trust" 690 Per Olafur Gudmundsson on 2/18/2013, address fact that ALL 691 authoritative name servers must be working. "section 10 you talk 692 about possible early removal the NTA when validation succeeds but 693 there may be instances where validation succeeds when using a sub-set 694 of the authoritative servers thus NTA should only be removed if all 695 servers are providing "good" signatures." 697 Per Olafur Gudmundsson on 2/18/2013, "Furthermore what to do if some 698 names work but others do not, for example I remember a case where the 699 records at the apex worked but all names below the apex were signed 700 by a key not in the DNSKEY RRset, thus it is possible that either 701 human or automated checks may assume there is no problem when there 702 actually is one. What this is bringing to my mind is maybe you want 703 a new section with guidelines on how to test for failures and in what 704 cases failure justifies NTA and what tests MUST pass before 705 preemttive removal of an NTA." 707 Per Olafur Gudmundsson on 2/18/2013, "Also should there be guidance 708 that removal of NTA should include cleaning the caches of all RRsets 709 below the name?" 710 Reference and text per Ed Lewis: One thing that seems to need 711 repeating from time to time is this passage in RFC 4033. ... In the 712 final analysis, however, authenticating both DNS keys and data is a 713 matter of local policy, which may extend or even override the 714 protocol extensions defined in this document set. See Section 5 for 715 further discussion. A responsibility (one of many) of a caching 716 server operator is to "protect the integrity of the cache." DNSSEC 717 is just a tool to help accomplish that. It carries ancillary data 718 that a local cache administrator may use to filter out undesired 719 responses. DNSSEC is not an enforcement mechanism, it's a resource. 720 When I see folks voice opinions that DNSSEC's recommended operation 721 has to strictly followed, my gut reaction is that these folks have 722 forgotten the purpose of all of our efforts. We don't secure 723 protocols to make things work better. We don't operate the DNS 724 because we like to run a well run machine. We don't run the Internet 725 for the fun of it. (Some might enjoy running it, that's job 726 satisfaction to some extent.) At the end of the day all that matters 727 is that what is being done benefits society. We run the Internet to 728 enrich society. We prefer a well run DNS because it saps less 729 resources than a poorly run DNS. We prefer secure protocols so that 730 people don't become victims (in some sense of the word). Make it 731 work. Do what it takes to make it work. "Local policy" rules. 733 Per David Conrad: I'd suggest that in the BCP/RFC/whatever, in 734 addition to recommending that NTAs be time capped and not written to 735 permanent storage, it should also recommend NTAs be written as 736 specifically as possible. (Should be obvious, but doesn't hurt to 737 reiterate I suppose). 739 Per Ralf Weber: Informing the domain owner on the validation failure. 740 There should be a section in the document that the operator deploying 741 an NTA has to inform the domain owner of the problem. (JL note: 742 would prefer to say operator SHOULD take reasonable steps to notify 743 the domain owner, etc.) 745 Authors' Addresses 747 Jason Livingood 748 Comcast Cable Communications 749 One Comcast Center 750 1701 John F. Kennedy Boulevard 751 Philadelphia, PA 19103 752 US 754 Email: jason_livingood@cable.comcast.com 755 URI: http://www.comcast.com 756 Chris Griffiths 757 Dyn