idnits 2.17.1 draft-livingood-dnsop-negative-trust-anchors-01.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 242: '...d in the operation of DNS servers MUST...' RFC 2119 keyword, line 268: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 269: '... Implementors SHOULD allow the opera...' RFC 2119 keyword, line 274: '...ive Trust Anchor MUST NOT be automatic...' RFC 2119 keyword, line 276: '...ive Trust Anchor SHOULD be used only i...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 555, but not defined == Unused Reference: 'DNSSEC-Validation-Failure-Analysis' is defined on line 505, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: April 26, 2015 Dyn 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 October 23, 2014 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-livingood-dnsop-negative-trust-anchors-01 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 those for non-DNSSEC-related domain 22 administration tools and processes. Negative Trust Anchors 23 (described in this document) can be used to mitigate DNSSEC 24 validation failures. 26 [ Editor note: This document was originally draft-livingood-negative- 27 trust-anchors-07 - renamved at the request of the DNSOP chairs ] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 26, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 3 65 3. delete . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Domain Validation Failures . . . . . . . . . . . . . . . . . 4 67 5. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 4 68 6. Switching to a Non-Validating Resolver is Not Recommended . . 5 69 7. Responsibility for Failures . . . . . . . . . . . . . . . . . 5 70 8. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 6 71 9. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 72 10. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 73 11. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 74 12. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 75 13. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 76 13.1. Security Considerations . . . . . . . . . . . . . . . . 8 77 13.2. Privacy Considerations . . . . . . . . . . . . . . . . . 9 78 13.3. IANA Considerations . . . . . . . . . . . . . . . . . . 9 79 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 15.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12 84 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 12 85 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 12 86 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 12 87 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13 88 Appendix C. 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] 95 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 96 [RFC5155]. 98 This document defines a Negative Trust Anchor, which can be used 99 during the transition to ubiquitous DNSSEC deployment. Negative 100 Trust Anchors (NTAs) are configured locally on a validating DNS 101 recursive resolver to shield end users from DNSSEC-related 102 authoritative name server operational errors. Negative Trust Anchors 103 are intended to be temporary, and should not be distributed by IANA 104 or any other organization outside of the administrative boundary of 105 the organization locally implementing a Negative Trust Anchor. 106 Finally, Negative Trust Anchors pertain only to DNSSEC and not to 107 Public Key Infrastructures (PKI) such as X.509. 109 DNSSEC has now entered widespread deployment. However, the DNSSEC 110 signing tools and processes are less mature and reliable than those 111 for non-DNSSEC-related administration. As a result, operators of DNS 112 recursive resolvers, such as Internet Service Providers (ISPs), 113 occasionally observe domains incorrectly managing DNSSEC-related 114 resource records. This mismanagement triggers DNSSEC validation 115 failures, and then causes large numbers of end users to be unable to 116 reach a domain. Many end users tend to interpret this as a failure 117 of their ISP or resolver operator, and may switch to a non-validating 118 resolver or contact their ISP to complain, rather than seeing this as 119 a failure on the part of the domain they wanted to reach. Without 120 the techniques in this document, this pressure may cause the resolver 121 operator to disable (or simply not deploy) DNSSEC validation. Use of 122 a Negative Trust Anchor to temporarily disable DNSSEC validation for 123 a specific misconfigured domain name immediately restores access for 124 end users. This allows the domain's administrators to fix their 125 misconfiguration, while also allowing the organization using the 126 Negative Trust Anchor to keep DNSSEC validation enabled and still 127 reach the misconfigured domain. 129 2. Definition of a Negative Trust Anchor 131 Trust Anchors are defined in [RFC5914]. A trust anchor should be 132 used by a validating caching resolver as a starting point for 133 building the authentication chain for a signed DNS response. The 134 inverse of this is a Negative Trust Anchor, which creates a stopping 135 point for a caching resolver to end validation of the authentication 136 chain. Instead, the resolver sends the response as if the zone is 137 unsigned and does not set the AD bit. This Negative Trust Anchor can 138 potentially be placed at any level within the chain of trust and 139 would stop validation from that point in the chain down. 141 3. delete 143 4. Domain Validation Failures 145 A domain name can fail validation for two general reasons: a 146 legitimate security failure such as due to an attack or compromise of 147 some sort, or as a result of misconfiguration on the part of an 148 domain administrator. As domains transition to DNSSEC the most 149 likely reason for a validation failure will be misconfiguration. 150 Thus, domain administrators should be sure to read [RFC6781] in full. 151 They should also pay special attention to Section 4.2, pertaining to 152 key rollovers, which appear to be the cause of many recent validation 153 failures. 155 It is also possible that some DNSSEC validation failures could arise 156 due to differences in how different software developers interpret 157 DNSSEC standards and/or how those developers choose to implement 158 support for DNSSEC. For example, it is conceivable that a domain may 159 be DNSSEC signed properly, and one vendor's DNS recursive resolvers 160 will validate the domain but other vendors' software may fail to 161 validate the domain. 163 5. End User Reaction 165 End users generally do not know what DNSSEC is, nor should they be 166 expected to at the current time (especially absent widespread 167 integration of DNSSEC indicators in end user software such as web 168 browsers). As a result, end users may misinterpret the failure to 169 reach a domain due to DNSSEC-related misconfiguration . They may 170 (incorrectly) assume that their ISP is purposely blocking access to 171 the domain or that it is a performance failure on the part of their 172 ISP (especially of the ISP's DNS servers). They may contact their 173 ISP to complain, which will incur cost for their ISP. In addition, 174 they may use online tools and sites to complain of this problem, such 175 as via a blog, web forum, or social media site, which may lead to 176 dissatisfaction on the part of other end users or general criticism 177 of an ISP or operator of a DNS recursive resolver. 179 As end users publicize these failures, others may recommend they 180 switch from security-aware DNS resolvers to resolvers not performing 181 DNSSEC validation. This is a shame since the ISP or other DNS 182 recursive resolver operator is actually doing exactly what they are 183 supposed to do in failing to resolve a domain name, as this is the 184 expected result when a domain can no longer be validated, protecting 185 end users from a potential security threat. Use of a Negative Trust 186 Anchor would allow the ISP to specifically remedy the failure to 187 reach that domain, without compromising security for other sites. 188 This would result in a satisfied end user, with minimal impact to the 189 ISP, while maintaining the security of DNSSEC for correctly 190 maintained domains. 192 6. Switching to a Non-Validating Resolver is Not Recommended 194 As noted in Section 5 some people may consider switching to an 195 alternative, non-validating resolver themselves, or may recommend 196 that others do so. But if a domain fails DNSSEC validation and is 197 inaccessible, this could very well be due to a security-related 198 issue. In order to be as safe and secure as possible, end users 199 should not change to DNS servers that do not perform DNSSEC 200 validation as a workaround, and people should not recommend that 201 others do so either. Domains that fail DNSSEC for legitimate reasons 202 (versus misconfiguration) may be in control of hackers or there could 203 be other significant security issues with the domain. 205 Thus, switching to a non-validating resolver to restore access to a 206 domain that fails DNSSEC validation is not a recommended practice, is 207 bad advice to others, is potentially harmful to end user security, 208 and is potentially harmful to DNSSEC adoption. 210 7. Responsibility for Failures 212 A domain administrator is solely and completely responsible for 213 managing their domain name(s) and DNS resource records. This 214 includes complete responsibility for the correctness of those 215 resource records, the proper functioning of their DNS authoritative 216 servers, and the correctness of DNS records linking their domain to a 217 top-level domain (TLD) or other higher level domain. Even in cases 218 where some error may be introduced by a third party, whether that is 219 due to an authoritative server software vendor, software tools 220 vendor, domain name registrar, or other organization, these are all 221 parties that the domain administrator has selected or approved, and 222 therefore is responsible for managing successfully. 224 There are some cases in which the domain administrator is not the 225 same as the domain owner. In those cases, a domain owner has 226 delegated operational responsibility to the domain administrator. So 227 no matter whether a domain owner is also the domain administrator or 228 not, the domain administrator is operationally responsible for the 229 proper configuration operation of the domain. 231 So in the case of a domain name failing to successfully validate, 232 when this is due to a misconfiguration of the domain, that is the 233 sole responsibility of the domain administrator. 235 Any assistance or mitigation responses undertaken by other parties to 236 mitigate the misconfiguration of a domain name by a domain 237 administrator, especially operators of DNS recursive resolvers, are 238 optional and at the pleasure of those parties. 240 8. Use of a Negative Trust Anchor 242 Technical personnel trained in the operation of DNS servers MUST 243 confirm that a failure is due to misconfiguration, as a similar 244 breakage could have occurred if an attacker gained access to a 245 domain's authoritative servers and modified those records or had the 246 domain pointed to their own rogue authoritative servers. They should 247 also confirm that the domain is not intentionally broken, such as for 248 testing purposes as noted in Section 12. Finally, they should make a 249 reasonable attempt to contact the domain owner of the misconfigured 250 zone, preferably prior to implementing the Negative Trust Anchor. 252 In the case of a validation failure due to misconfiguration of a TLD 253 or popular domain name (such as a top 100 website), this could make 254 content or services in the affected TLD or domain inaccessible for a 255 large number of users. In such cases, it may be appropriate to use a 256 Negative Trust Anchor as soon as the misconfiguration is confirmed. 258 Once a domain has been confirmed to fail DNSSEC validation due to a 259 DNSSEC-related misconfiguration, an ISP or other DNS recursive 260 resolver operator may elect to use a Negative Trust Anchor for that 261 domain or sub-domain. This instructs their DNS recursive resolver to 262 temporarily NOT perform DNSSEC validation at or in the misconfigured 263 domain. This immediately restores access to the domain for end users 264 while the domain's administrator corrects the misconfiguration(s). 265 It does not and should not involve turning off validation more 266 broadly. 268 A Negative Trust Anchor MUST only be used for a limited duration. 269 Implementors SHOULD allow the operator using the Negative Trust 270 Andhor to set an end time and date associated with any Negative Trust 271 Anchor. Optimally this time and date is set in a DNS recursive 272 resolver's configuration, though in the short-term this may also be 273 achieved via other systems or supporting processes. Use of a 274 Negative Trust Anchor MUST NOT be automatic. 276 Finally, a Negative Trust Anchor SHOULD be used only in a specific 277 domain or sub-domain and MUST NOT affect validation of other names up 278 the authentication chain. For example, a Negative Trust Anchor for 279 zone1.example.com would affect only names at or below 280 zone1.example.com, and validation would still be performed on 281 example.com, .com, and the root ("."). In another example, a 282 Negative Trust Anchor for example.com would affect only names within 283 example.com, and validation would still be performed on .com, and the 284 root (".") 286 Root (.) <====== 287 | || 288 | ||<======>+----+----+ DNSSEC 289 | || |Recursive| Validation 290 TLD (com) <=====|| |Resolver |<============> 291 | +<------>+---------+ 292 | | DNS NTA 293 | | (example.com) 294 SUB TLD (example.com) <------| <--------------> 295 | | 296 | | 297 | | 298 (zone1.example.com <-----| 300 Figure 1: Negative Trust Anchor Diagram 302 9. Managing Negative Trust Anchors 304 While Negative Trust Anchors have proven useful during the early 305 stages of DNSSEC adoption, domain owners are ultimately responsible 306 for managing and ensuring their DNS records are configured correctly 307 Section 7. 309 Most current implementations of DNS validating resolvers currently 310 follow [RFC4033] on defining the implementation of Trust Anchor as 311 either using Delegation Signer (DS), Key Signing Key (KSK), or Zone 312 Signing Key (ZSK). A Negative Trust Anchor should use domain name 313 formatting that signifies where in a delegation a validation process 314 should be stopped. 316 Different DNS recursive resolvers may have different configuration 317 names for a Negative Trust Anchor. For example, Unbound calls their 318 configuration "domain-insecure." 320 [need to update reference to full Appendix A, not just unbound] 322 [Unbound-Configuration] 324 10. Removal of a Negative Trust Anchor 326 As explored in Section 13.1, using an NTA once the zone correctly 327 validates can have security considerations. It is therefore 328 recommended that NTA implementors should periodically attempt to 329 validate the domain in question, for the period of time that the 330 Negative Trust Anchor is in place, until such validation is again 331 successful. Before removing the Negative Trust Anchor, all 332 authoritive resolvers listed in the zone should be checked. Due to 333 AnyCast or load balancers, this may not be possible. 335 Once all testing succeeds, a Negative Trust Anchor should be removed 336 as soon as is reasonably possible. Optimally this is automatic, 337 though it may also be achieved via other systems or supporting 338 processes. 340 11. Comparison to Other DNS Misconfigurations 342 As noted in Section 7 domain administrators are ultimately 343 responsible for managing and ensuring their DNS records are 344 configured correctly. ISPs or other DNS recursive resolver operators 345 cannot and should not correct misconfigured A, CNAME, MX, or other 346 resource records of domains for which they are not authoritative. 347 Expecting non-authoritative entities to protect domain administrators 348 from any misconfiguration of resource records is therefore 349 unrealistic and unreasonable, and in the long-term is harmful to the 350 delegated design of the DNS and could lead to extensive operational 351 instability and/or variation. 353 12. Intentionally Broken Domains 355 Some domains, such as dnssec-failed.org, have been intentionally 356 broken for testing purposes 357 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 358 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 359 If an end user is querying a validating DNS recursive resolver, then 360 this or other similarly intentionally broken domains should fail to 361 resolve and should result in a SERVFAIL error. If such a domain 362 resolved successfully, then it is a sign that the DNS recursive 363 resolver is not fully validating. 365 Organizations that utilize Negative Trust Anchors should not add a 366 Negative Trust Anchor for any intentionally broken domain. 368 Organizations operating an intentionally broken domain may wish to 369 consider adding a TXT record for the domain to the effect of "This 370 domain is purposely DNSSEC broken for testing purposes". 372 13. Other Considerations 374 13.1. Security Considerations 376 End to end DNSSEC validation will be disabled during the time that a 377 Negative Trust Anchor is used. In addition, the Negative Trust 378 Anchor may be in place after the point in time when the DNS 379 misconfiguration that caused validation to break has been fixed. 380 Thus, there may be a gap between when a domain has have been re- 381 secured and when a Negative Trust Anchor is removed. In addition, a 382 Negative Trust Anchor may be put in place by DNS recursive resolver 383 operators without the knowledge of the authoritative domain 384 administrator for a given domain name. However, attempts SHOULD be 385 made to contact and inform the domain administrator prior to putting 386 the NTA in place. 388 End users of a DNS recursive resolver or other people may wonder why 389 a domain that fails DNSSEC validation resolves with a supposedly 390 validating resolver. As a result, implementors should consider 391 transparently disclosing those Negative Trust Anchors which are 392 currently in place or were in place in the past, such as on a website 393 [Disclosure-Example]. This is particularly important since there is 394 currently no special DNS query response code that could indicate to 395 end users or applications that a Negative Trust Anchor is in place. 396 Such disclosures should optimally include both the data and time that 397 the Negative Trust Anchor was put in place and when it was removed. 399 13.2. Privacy Considerations 401 There are no privacy considerations in this document. 403 13.3. IANA Considerations 405 There are no IANA considerations in this document. 407 14. Acknowledgements 409 Several people made contributions of text to this document and/or 410 played an important role in the development and evolution of this 411 document. This in some cases included performing a detailed review 412 of this document and then providing feedback and constructive 413 criticism for future revisions, or engaging in a healthy debate over 414 the subject of the document. All of this was helpful and therefore 415 the following individuals merit acknowledgement: 417 - Joe Abley 419 - John Barnitz 421 - Tom Creighton 423 - Marco Davids 425 - Brian Dickson 426 - Patrik Falstrom 428 - Tony Finch 430 - Chris Ganster 432 - Olafur Gudmundsson 434 - Peter Hagopian 436 - Wes Hardaker 438 - Paul Hoffman 440 - Shane Kerr 442 - Murray Kucherawy 444 - Warren Kumari 446 - Rick Lamb 448 - Marc Lampo 450 - Ted Lemon 452 - Ed Lewis 454 - Antoin Verschuren 456 - Paul Vixie 458 - Patrik Wallstrom 460 - Nick Weaver 462 - Ralf Weber 464 15. References 466 15.1. Normative References 468 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 469 STD 13, RFC 1034, November 1987. 471 [RFC1035] Mockapetris, P., "Domain names - implementation and 472 specification", STD 13, RFC 1035, November 1987. 474 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 475 Rose, "DNS Security Introduction and Requirements", RFC 476 4033, March 2005. 478 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 479 Rose, "Resource Records for the DNS Security Extensions", 480 RFC 4034, March 2005. 482 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 483 Rose, "Protocol Modifications for the DNS Security 484 Extensions", RFC 4035, March 2005. 486 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 487 System (DNS)", RFC 4398, March 2006. 489 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 490 (DS) Resource Records (RRs)", RFC 4509, May 2006. 492 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 493 Security (DNSSEC) Hashed Authenticated Denial of 494 Existence", RFC 5155, March 2008. 496 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 497 Format", RFC 5914, June 2010. 499 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 500 Operational Practices, Version 2", RFC 6781, December 501 2012. 503 15.2. Informative References 505 [DNSSEC-Validation-Failure-Analysis] 506 Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., 507 and J. Livingood, "Analysis of DNSSEC Validation Failure - 508 NASA.GOV", Comcast , January 2012, 509 . 512 [Disclosure-Example] 513 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 514 Comcast , February 2013, . 517 [Measuring-DNSSEC-Validation-of-Website-Visitors] 518 Mens, J., "Is my Web site being used via a DNSSEC- 519 validator?", July 2012, . 522 [Netalyzr] 523 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 524 "Implications of Netalyzr's DNS Measurements", Securing 525 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 526 2011, . 529 [Unbound-Configuration] 530 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 531 2010, . 534 Appendix A. Configuration Examples 536 The section contains example configurations to achive Negative Trust 537 Anchor funcationality for the zone foo.example.com. 539 Please note: These are simply examples - nameserver operators are 540 expected to test and understand the implications of these operations. 542 A.1. NLNet Labs Unbound 544 Unbound lets us simply disable validation eching for a specific zone. 545 See: [ 546 TODO(WK): Make this a "real" reference ] 548 server: 549 domain-insecure: "foo.example.com" 551 A.2. ISC BIND 553 Use the "rndc" command: 555 _rndc nta [-lifetime duration] [-force] foo.example.com [view]_ 557 Set a negative trust anchor, disabling DNSSEC validation for the 558 given domain. Using -lifetime specifies the duration of the NTA, up 559 to one day. Using -force prevents the NTA from expiring before its 560 full lifetime, even if the domain can validate sooner. 562 A.3. Nominum Vantio 564 ** 566 *negative-trust-anchors* 568 _Format_: name 569 _Command Channel_: view.update name=world negative-trust- 570 anchors=(foo.example.com) 572 _Command Channel_: resolver.update name=res1 negative-trust- 573 anchors=(foo.example.com) 575 *Description*: Disables DNSSEC validation for a domain, even if the 576 domain is under an existing security root. 578 Appendix B. Document Change Log 580 [RFC Editor: This section is to be removed before publication] 582 Individual-00: First version published as an individual draft. 584 Individual-01: Fixed minor typos and grammatical nits. Closed all 585 open editorial items. 587 Individual-02: Simple date change to keep doc from expiring. 588 Substantive updates planned. 590 Individual-03: Changes to address feedback from Paul Vixie, by adding 591 a new section "Limited Time and Scope of Use". Changes to address 592 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 593 new section "Intentionally Broken Domains" and added two related 594 references. Added text to address the need for manual investigation, 595 as suggested by Patrik Falstrom. Added a suggestion on notification 596 as suggested by Marc Lampo. Made several additions and changes 597 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 598 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 600 Individual-04: Moved the section defining a NTA forward, and added 601 new text to the Abstract and Introduction per feedback from Paul 602 Hoffman. 604 Individual-05: Incorporated feedback from the DNSOP WG list received 605 on 2/17/13 and 2/18/13. This is likely the final version before the 606 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 607 per March Davids. 609 Individual-06: Added more OPEN issues to continue tracking WG 610 discussion. No changes in the main document - just expanded issue 611 tracking. 613 Individual-07: Refresh document - needs revision and rework before 614 IETF-91. Planning to add more contributors. 616 WG-00: Renamed at request of DNSOP co-chairs, added co-authors 617 WG-00 (cont): 619 o Using github issue tracker - go see https://github.com/wkumari/ 620 draft-livingood-dnsop-negative-trust-anchors/issues for more 621 details. 623 o A bunch of readability improvments. 625 o Issue: Notify the domain owner of the validation failure - 626 resolved. 628 o Issue: Make the NTA as specific as possible - resolved. 630 Appendix C. Open Issues 632 [RFC Editor: This section is to be removed before publication] 634 Determine whether RFC 2119 language should be used or not when 635 describing things like the duration of a NTA. 637 The DNSOP WG should discuss whether a 1 day limit is reasonable, 638 whether a different time (more or less than 1 day, such as 1 hour or 639 1 week) should be specified, or whether no time should be specified 640 (just a recommendation that it SHOULD generally be limited to X). 642 Olafur Gudmundsson has suggested that we may want to consider whether 643 a non validatable RRSIG should be returned or not when a NTA is in 644 place. This was raised in the context of NLnet Labs' DNSSEC-Trigger, 645 which apparently acts like forwarding stub-validator. He said, "The 646 reason for this is if NTA strips signatures the stub-validator thinks 647 it is under attack and may a) go into recursive mode to try to 648 resolve the domain, getting to the right answer the long way. b) Give 649 the wrong error "Missing signatures" instead of the real error. If 650 all the validator does is not to set the AD bit for RRsets at and 651 below the NTA, stub-resolvers (and cascading resolvers) should be 652 happy." 654 Determine whether an informative reference to X.509 in the 655 Introduction is necessary. 657 Is it desirable to say that NTAs should not be distributed across 658 organizational boundaries? 660 Per Warren Kumari, add examples to appendix. "it would be very 661 helpful to actually show how this is used, with e.g and example in an 662 Appendix, for -insert favorite resolver here-. The document contains 663 a lot of really useful content about why you might use one, how to 664 minimize damage, etc but (IMO) does't do a great job of explaining 665 how to actually do so". Rick Lamb and Joe Abley also agreed on the 666 need for this. 668 Per Rick Lamb, "it might be useful to have section 2 "Definition .." 669 make that clear for slow people like me - that the NTA is not an RR 670 and is more of a configuration. Maybe simply replacing "placed" with 671 "implemented" in section 2? "This NTA can potentially be -placed/ 672 implemented- at any level within the chain of trust" 674 Per Olafur Gudmundsson, address fact that ALL authoritative name 675 servers must be working. "section 10 you talk about possible early 676 removal the NTA when validation succeeds but there may be instances 677 where validation succeeds when using a sub-set of the authoritative 678 servers thus NTA should only be removed if all servers are providing 679 "good" signatures." 681 Per Olafur Gudmundsson, "Furthermore what to do if some names work 682 but others do not, for example I remember a case where the records at 683 the apex worked but all names below the apex were signed by a key not 684 in the DNSKEY RRset, thus it is possible that either human or 685 automated checks may assume there is no problem when there actually 686 is one. What this is bringing to my mind is maybe you want a new 687 section with guidelines on how to test for failures and in what cases 688 failure justifies NTA and what tests MUST pass before preemttive 689 removal of an NTA." 691 Per Olafur Gudmundsson, "Also should there be guidance that removal 692 of NTA should include cleaning the caches of all RRsets below the 693 name?" 695 Reference and text per Ed Lewis: One thing that seems to need 696 repeating from time to time is this passage in RFC 4033. ... In the 697 final analysis, however, authenticating both DNS keys and data is a 698 matter of local policy, which may extend or even override the 699 protocol extensions defined in this document set. See Section 5 for 700 further discussion. A responsibility (one of many) of a caching 701 server operator is to "protect the integrity of the cache." DNSSEC 702 is just a tool to help accomplish that. It carries ancillary data 703 that a local cache administrator may use to filter out undesired 704 responses. DNSSEC is not an enforcement mechanism, it's a resource. 705 When I see folks voice opinions that DNSSEC's recommended operation 706 has to strictly followed, my gut reaction is that these folks have 707 forgotten the purpose of all of our efforts. We don't secure 708 protocols to make things work better. We don't operate the DNS 709 because we like to run a well run machine. We don't run the Internet 710 for the fun of it. (Some might enjoy running it, that's job 711 satisfaction to some extent.) At the end of the day all that matters 712 is that what is being done benefits society. We run the Internet to 713 enrich society. We prefer a well run DNS because it saps less 714 resources than a poorly run DNS. We prefer secure protocols so that 715 people don't become victims (in some sense of the word). Make it 716 work. Do what it takes to make it work. "Local policy" rules. 718 Per David Conrad: I'd suggest that in the BCP/RFC/whatever, in 719 addition to recommending that NTAs be time capped and not written to 720 permanent storage, it should also recommend NTAs be written as 721 specifically as possible. (Should be obvious, but doesn't hurt to 722 reiterate I suppose). 724 Per Ralf Weber: Informing the domain owner on the validation failure. 725 There should be a section in the document that the operator deploying 726 an NTA has to inform the domain owner of the problem. (JL note: 727 would prefer to say operator SHOULD take reasonable steps to notify 728 the domain owner, etc.) 730 Authors' Addresses 732 Paul Ebersman 733 Comcast 734 One Comcast Center 735 1701 John F. Kennedy Boulevard 736 Philadelphia, PA 19103 737 US 739 Email: ebersman-ietf@dragon.net 741 Chris Griffiths 742 Dyn 743 150 Dow Street 744 Tower Two 745 Manchester, NH 03101 746 US 748 Email: cgriffiths@gmail.com 749 URI: http://www.dyn.com 751 Warren Kumari 752 Google 753 1600 Amphitheatre Parkway 754 Mountain View, CA 94043 755 US 757 Email: warren@kumari.net 758 URI: http://www.google.com 759 Jason Livingood 760 Comcast 761 One Comcast Center 762 1701 John F. Kennedy Boulevard 763 Philadelphia, PA 19103 764 US 766 Email: jason_livingood@cable.comcast.com 767 URI: http://www.comcast.com 769 Ralf Weber 770 Nominum 772 Email: Ralf.Weber@nominum.com 773 URI: http://www.nominum.com