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