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