idnits 2.17.00 (12 Aug 2021) /tmp/idnits59746/draft-ietf-dnsop-negative-trust-anchors-02.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 265: '...d in the operation of DNS servers MUST...' RFC 2119 keyword, line 292: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 293: '... Implementors SHOULD allow the opera...' RFC 2119 keyword, line 298: '...ive Trust Anchor MUST NOT be automatic...' RFC 2119 keyword, line 300: '...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 (March 04, 2015) is 2635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 594, but not defined == Unused Reference: 'DNSSEC-Validation-Failure-Analysis' is defined on line 542, 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: September 5, 2015 Dyn 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 March 04, 2015 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-ietf-dnsop-negative-trust-anchors-02 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 [RFC Editor: Please remove this before publication. This document is 27 being stored in github at https://github.com/wkumari/draft-livingood- 28 dnsop-negative-trust-anchors . Authors accept pull requests, and keep 29 the latest (edit buffer) versions there, so commenters can follow 30 along at home.] 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 5, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 4 68 3. Domain Validation Failures . . . . . . . . . . . . . . . . . 4 69 4. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Switching to a Non-Validating Resolver is Not Recommended . . 5 71 6. Responsibility for Failures . . . . . . . . . . . . . . . . . 5 72 7. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 6 73 8. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 74 9. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 8 75 10. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 76 11. Intentionally Broken Domains . . . . . . . . . . . . . . . . 9 77 12. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 78 12.1. Security Considerations . . . . . . . . . . . . . . . . 9 79 12.2. Privacy Considerations . . . . . . . . . . . . . . . . . 10 80 12.3. IANA Considerations . . . . . . . . . . . . . . . . . . 10 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 14.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12 86 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13 87 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13 88 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 13 89 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and 95 related operational practices are defined extensively [RFC1034] 97 [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] 98 [RFC5155]. 100 This document defines a Negative Trust Anchor, which can be used 101 during the transition to ubiquitous DNSSEC deployment. Negative 102 Trust Anchors (NTAs) are configured locally on a validating DNS 103 recursive resolver to shield end users from DNSSEC-related 104 authoritative name server operational errors. Negative Trust Anchors 105 are intended to be temporary, and should not be distributed by IANA 106 or any other organization outside of the administrative boundary of 107 the organization locally implementing a Negative Trust Anchor. 108 Finally, Negative Trust Anchors pertain only to DNSSEC and not to 109 Public Key Infrastructures (PKI) such as X.509. 111 DNSSEC has now entered widespread deployment. However, the DNSSEC 112 signing tools and processes are less mature and reliable than those 113 for non-DNSSEC-related administration. As a result, operators of DNS 114 recursive resolvers, such as Internet Service Providers (ISPs), 115 occasionally observe domains incorrectly managing DNSSEC-related 116 resource records. This mismanagement triggers DNSSEC validation 117 failures, and then causes large numbers of end users to be unable to 118 reach a domain. Many end users tend to interpret this as a failure 119 of their ISP or resolver operator, and may switch to a non-validating 120 resolver or contact their ISP to complain, rather than seeing this as 121 a failure on the part of the domain they wanted to reach. Without 122 the techniques in this document, this pressure may cause the resolver 123 operator to disable (or simply not deploy) DNSSEC validation. Use of 124 a Negative Trust Anchor to temporarily disable DNSSEC validation for 125 a specific misconfigured domain name immediately restores access for 126 end users. This allows the domain's administrators to fix their 127 misconfiguration, while also allowing the organization using the 128 Negative Trust Anchor to keep DNSSEC validation enabled and still 129 reach the misconfigured domain. 131 It is worth noting the following text from RFC4033 [RFC4033] - "In 132 the final analysis, however, authenticating both DNS keys and data is 133 a matter of local policy, which may extend or even override the 134 protocol extensions defined in this document set." A responsibility 135 (one of many) of a caching server operator is to "protect the 136 integrity of the cache." DNSSEC is just a tool to help accomplish 137 that. It carries ancillary data that a local cache administrator may 138 use to filter out undesired responses. DNSSEC is not an enforcement 139 mechanism, it's a resource. When I see folks voice opinions that 140 DNSSEC's recommended operation has to strictly followed, my gut 141 reaction is that these folks have forgotten the purpose of all of our 142 efforts. We don't secure protocols to make things work better. We 143 don't operate the DNS because we like to run a well run machine. We 144 don't run the Internet for the fun of it. (Some might enjoy running 145 it, that's job satisfaction to some extent.) At the end of the day 146 all that matters is that what is being done benefits society. We run 147 the Internet to enrich society. We prefer a well run DNS because it 148 saps less resources than a poorly run DNS. We prefer secure 149 protocols so that people don't become victims (in some sense of the 150 word). Make it work. Do what it takes to make it work. "Local 151 policy" rules. 153 2. Definition of a Negative Trust Anchor 155 Trust Anchors are defined in [RFC5914]. A trust anchor should be 156 used by a validating caching resolver as a starting point for 157 building the authentication chain for a signed DNS response. The 158 inverse of this is a Negative Trust Anchor, which creates a stopping 159 point for a caching resolver to end validation of the authentication 160 chain. Instead, the resolver sends the response as if the zone is 161 unsigned and does not set the AD bit. Note that this is a behavior, 162 and not a separate resource record. This Negative Trust Anchor can 163 potentially be implemented at any level within the chain of trust and 164 would stop validation from that point in the chain down. 166 3. Domain Validation Failures 168 A domain name can fail validation for two general reasons: a 169 legitimate security failure such as due to an attack or compromise of 170 some sort, or as a result of misconfiguration on the part of an 171 domain administrator. As domains transition to DNSSEC, the most 172 likely reason for a validation failure will be misconfiguration. 173 Thus, domain administrators should be sure to read [RFC6781] in full. 174 They should also pay special attention to Section 4.2, pertaining to 175 key rollovers, which appear to be the cause of many recent validation 176 failures. 178 It is also possible that some DNSSEC validation failures could arise 179 due to differences in how different software developers interpret 180 DNSSEC standards and/or how those developers choose to implement 181 support for DNSSEC. For example, it is conceivable that a domain may 182 be DNSSEC signed properly, and one vendor's DNS recursive resolvers 183 will validate the domain but other vendors' software may fail to 184 validate the domain. 186 4. End User Reaction 188 End users generally do not know what DNSSEC is, nor should they be 189 expected to at the current time (especially absent widespread 190 integration of DNSSEC indicators in end user software such as web 191 browsers). As a result, end users may misinterpret the failure to 192 reach a domain due to DNSSEC-related misconfiguration . They may 193 (incorrectly) assume that their ISP is purposely blocking access to 194 the domain or that it is a performance failure on the part of their 195 ISP (especially of the ISP's DNS servers). They may contact their 196 ISP to complain, which will incur cost for their ISP. In addition, 197 they may use online tools and sites to complain of this problem, such 198 as via a blog, web forum, or social media site, which may lead to 199 dissatisfaction on the part of other end users or general criticism 200 of an ISP or operator of a DNS recursive resolver. 202 As end users publicize these failures, others may recommend they 203 switch from security-aware DNS resolvers to resolvers not performing 204 DNSSEC validation. This is a shame since the ISP or other DNS 205 recursive resolver operator is actually doing exactly what they are 206 supposed to do in failing to resolve a domain name, as this is the 207 expected result when a domain can no longer be validated, protecting 208 end users from a potential security threat. Use of a Negative Trust 209 Anchor would allow the ISP to specifically remedy the failure to 210 reach that domain, without compromising security for other sites. 211 This would result in a satisfied end user, with minimal impact to the 212 ISP, while maintaining the security of DNSSEC for correctly 213 maintained domains. 215 5. Switching to a Non-Validating Resolver is Not Recommended 217 As noted in Section 4, some people may consider switching to an 218 alternative, non-validating resolver themselves, or may recommend 219 that others do so. But if a domain fails DNSSEC validation and is 220 inaccessible, this could very well be due to a security-related 221 issue. In order to be as safe and secure as possible, end users 222 should not change to DNS servers that do not perform DNSSEC 223 validation as a workaround, and people should not recommend that 224 others do so either. Domains that fail DNSSEC for legitimate reasons 225 (versus misconfiguration) may be in control of hackers or there could 226 be other significant security issues with the domain. 228 Thus, switching to a non-validating resolver to restore access to a 229 domain that fails DNSSEC validation is not a recommended practice, is 230 bad advice to others, is potentially harmful to end user security, 231 and is potentially harmful to DNSSEC adoption. 233 6. Responsibility for Failures 235 A domain administrator is solely and completely responsible for 236 managing their domain name(s) and DNS resource records. This 237 includes complete responsibility for the correctness of those 238 resource records, the proper functioning of their DNS authoritative 239 servers, and the correctness of DNS records linking their domain to a 240 top-level domain (TLD) or other higher level domain. Even in cases 241 where some error may be introduced by a third party, whether that is 242 due to an authoritative server software vendor, software tools 243 vendor, domain name registrar, or other organization, these are all 244 parties that the domain administrator has selected or approved, and 245 therefore is responsible for managing successfully. 247 There are some cases in which the domain administrator is not the 248 same as the domain owner. In those cases, a domain owner has 249 delegated operational responsibility to the domain administrator. So 250 no matter whether a domain owner is also the domain administrator or 251 not, the domain administrator is operationally responsible for the 252 proper configuration operation of the domain. 254 So in the case of a domain name failing to successfully validate, 255 when this is due to a misconfiguration of the domain, that is the 256 sole responsibility of the domain administrator. 258 Any assistance or mitigation responses undertaken by other parties to 259 mitigate the misconfiguration of a domain name by a domain 260 administrator, especially operators of DNS recursive resolvers, are 261 optional and at the pleasure of those parties. 263 7. Use of a Negative Trust Anchor 265 Technical personnel trained in the operation of DNS servers MUST 266 confirm that a failure is due to misconfiguration, as a similar 267 breakage could have occurred if an attacker gained access to a 268 domain's authoritative servers and modified those records or had the 269 domain pointed to their own rogue authoritative servers. They should 270 also confirm that the domain is not intentionally broken, such as for 271 testing purposes as noted in Section 11. Finally, they should make a 272 reasonable attempt to contact the domain owner of the misconfigured 273 zone, preferably prior to implementing the Negative Trust Anchor. 275 In the case of a validation failure due to misconfiguration of a TLD 276 or popular domain name (such as a top 100 website), this could make 277 content or services in the affected TLD or domain inaccessible for a 278 large number of users. In such cases, it may be appropriate to use a 279 Negative Trust Anchor as soon as the misconfiguration is confirmed. 281 Once a domain has been confirmed to fail DNSSEC validation due to a 282 DNSSEC-related misconfiguration, an ISP or other DNS recursive 283 resolver operator may elect to use a Negative Trust Anchor for that 284 domain or sub-domain. This instructs their DNS recursive resolver to 285 temporarily NOT perform DNSSEC validation at or in the misconfigured 286 domain. This immediately restores access to the domain for end users 287 while the domain's administrator corrects the misconfiguration(s). 289 It does not and should not involve turning off validation more 290 broadly. 292 A Negative Trust Anchor MUST only be used for a limited duration. 293 Implementors SHOULD allow the operator using the Negative Trust 294 Anchor to set an end time and date associated with any Negative Trust 295 Anchor. Optimally this time and date is set in a DNS recursive 296 resolver's configuration, though in the short-term this may also be 297 achieved via other systems or supporting processes. Use of a 298 Negative Trust Anchor MUST NOT be automatic. 300 Finally, a Negative Trust Anchor SHOULD be used only in a specific 301 domain or sub-domain and MUST NOT affect validation of other names up 302 the authentication chain. For example, a Negative Trust Anchor for 303 zone1.example.com would affect only names at or below 304 zone1.example.com, and validation would still be performed on 305 example.com, .com, and the root ("."). In another example, a 306 Negative Trust Anchor for example.com would affect only names within 307 example.com, and validation would still be performed on .com, and the 308 root (".") 310 Root (.) <====== 311 | || 312 | ||<======>+----+----+ DNSSEC 313 | || |Recursive| Validation 314 TLD (com) <=====|| |Resolver |<============> 315 | +<------>+---------+ 316 | | DNS NTA 317 | | (example.com) 318 SUB TLD (example.com) <------| <--------------> 319 | | 320 | | 321 | | 322 (zone1.example.com <-----| 324 Figure 1: Negative Trust Anchor Diagram 326 8. Managing Negative Trust Anchors 328 While Negative Trust Anchors have proven useful during the early 329 stages of DNSSEC adoption, domain owners are ultimately responsible 330 for managing and ensuring their DNS records are configured correctly 331 Section 6. 333 Most current implementations of DNS validating resolvers currently 334 follow [RFC4033] on defining the implementation of Trust Anchor as 335 either using Delegation Signer (DS), Key Signing Key (KSK), or Zone 336 Signing Key (ZSK). A Negative Trust Anchor should use domain name 337 formatting that signifies where in a delegation a validation process 338 should be stopped. 340 Different DNS recursive resolvers may have different configuration 341 names for a Negative Trust Anchor. For example, Unbound calls their 342 configuration "domain-insecure." 344 [Unbound-Configuration] 346 9. Removal of a Negative Trust Anchor 348 As explored in Section 12.1, using an NTA once the zone correctly 349 validates can have security considerations. It is therefore 350 recommended that NTA implementors should periodically attempt to 351 validate the domain in question, for the period of time that the 352 Negative Trust Anchor is in place, until such validation is again 353 successful. NTAs MUST expire automatically when their configured 354 lifetime ends. The lifetime MUST NOT exceed a week. Before removing 355 the Negative Trust Anchor, all authoritative resolvers listed in the 356 zone should be checked (due to anycast and load balancers it may not 357 be possible to check all instances). 359 Once all testing succeeds, a Negative Trust Anchor should be removed 360 as soon as is reasonably possible. One possible method to 361 automatically determine when the NTA can be removed is to send a 362 periodic query for type SOA at the NTA node; if it gets a response 363 that it can validate (whether the response was an actual SOA answer 364 or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is 365 presumed no longer to be necessary and is removed. Implementations 366 SHOULD, by default, perform this operation. Note that under some 367 circumstances this is undesirable behavior (for example, if 368 www.example.com has a bad signature, but example.com/SOA is fine) and 369 so implementations may wish to allow the operator to override this 370 spot-check / behavior. 372 When removing the NTA, the implementation should remove all cached 373 entries below the NTA node. 375 10. Comparison to Other DNS Misconfigurations 377 As noted in Section 6, domain administrators are ultimately 378 responsible for managing and ensuring their DNS records are 379 configured correctly. ISPs or other DNS recursive resolver operators 380 cannot and should not correct misconfigured A, CNAME, MX, or other 381 resource records of domains for which they are not authoritative. 382 Expecting non-authoritative entities to protect domain administrators 383 from any misconfiguration of resource records is therefore 384 unrealistic and unreasonable, and in the long-term is harmful to the 385 delegated design of the DNS and could lead to extensive operational 386 instability and/or variation. 388 11. Intentionally Broken Domains 390 Some domains, such as dnssec-failed.org, have been intentionally 391 broken for testing purposes 392 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 393 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 394 If an end user is querying a validating DNS recursive resolver, then 395 this or other similarly intentionally broken domains should fail to 396 resolve and should result in a SERVFAIL error. If such a domain 397 resolved successfully, then it is a sign that the DNS recursive 398 resolver is not fully validating. 400 Organizations that utilize Negative Trust Anchors should not add a 401 Negative Trust Anchor for any intentionally broken domain. 403 Organizations operating an intentionally broken domain may wish to 404 consider adding a TXT record for the domain to the effect of "This 405 domain is purposely DNSSEC broken for testing purposes". 407 12. Other Considerations 409 12.1. Security Considerations 411 End to end DNSSEC validation will be disabled during the time that a 412 Negative Trust Anchor is used. In addition, the Negative Trust 413 Anchor may be in place after the point in time when the DNS 414 misconfiguration that caused validation to break has been fixed. 415 Thus, there may be a gap between when a domain has have been re- 416 secured and when a Negative Trust Anchor is removed. In addition, a 417 Negative Trust Anchor may be put in place by DNS recursive resolver 418 operators without the knowledge of the authoritative domain 419 administrator for a given domain name. However, attempts SHOULD be 420 made to contact and inform the domain administrator prior to putting 421 the NTA in place. 423 End users of a DNS recursive resolver or other people may wonder why 424 a domain that fails DNSSEC validation resolves with a supposedly 425 validating resolver. As a result, implementors should consider 426 transparently disclosing those Negative Trust Anchors which are 427 currently in place or were in place in the past, such as on a website 428 [Disclosure-Example]. This is particularly important since there is 429 currently no special DNS query response code that could indicate to 430 end users or applications that a Negative Trust Anchor is in place. 431 Such disclosures should optimally include both the data and time that 432 the Negative Trust Anchor was put in place and when it was removed. 434 12.2. Privacy Considerations 436 There are no privacy considerations in this document. 438 12.3. IANA Considerations 440 There are no IANA considerations in this document. 442 13. Acknowledgements 444 Several people made contributions of text to this document and/or 445 played an important role in the development and evolution of this 446 document. This in some cases included performing a detailed review 447 of this document and then providing feedback and constructive 448 criticism for future revisions, or engaging in a healthy debate over 449 the subject of the document. All of this was helpful and therefore 450 the following individuals merit acknowledgement: 452 - Joe Abley 454 - John Barnitz 456 - Tom Creighton 458 - Marco Davids 460 - Brian Dickson 462 - Patrik Falstrom 464 - Tony Finch 466 - Chris Ganster 468 - Olafur Gudmundsson 470 - Peter Hagopian 472 - Wes Hardaker 474 - Paul Hoffman 476 - Shane Kerr 478 - Murray Kucherawy 480 - Warren Kumari 481 - Rick Lamb 483 - Marc Lampo 485 - Ted Lemon 487 - Ed Lewis 489 - Antoin Verschuren 491 - Paul Vixie 493 - Patrik Wallstrom 495 - Nick Weaver 497 - Ralf Weber 499 Edward Lewis and Evan Hunt provided especially large amounts of text. 501 14. References 503 14.1. Normative References 505 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 506 STD 13, RFC 1034, November 1987. 508 [RFC1035] Mockapetris, P., "Domain names - implementation and 509 specification", STD 13, RFC 1035, November 1987. 511 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 512 Rose, "DNS Security Introduction and Requirements", RFC 513 4033, March 2005. 515 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 516 Rose, "Resource Records for the DNS Security Extensions", 517 RFC 4034, March 2005. 519 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 520 Rose, "Protocol Modifications for the DNS Security 521 Extensions", RFC 4035, March 2005. 523 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 524 System (DNS)", RFC 4398, March 2006. 526 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 527 (DS) Resource Records (RRs)", RFC 4509, May 2006. 529 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 530 Security (DNSSEC) Hashed Authenticated Denial of 531 Existence", RFC 5155, March 2008. 533 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 534 Format", RFC 5914, June 2010. 536 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 537 Operational Practices, Version 2", RFC 6781, December 538 2012. 540 14.2. Informative References 542 [DNSSEC-Validation-Failure-Analysis] 543 Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., 544 and J. Livingood, "Analysis of DNSSEC Validation Failure - 545 NASA.GOV", Comcast , January 2012, 546 . 549 [Disclosure-Example] 550 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 551 Comcast , February 2013, . 554 [Measuring-DNSSEC-Validation-of-Website-Visitors] 555 Mens, J., "Is my Web site being used via a DNSSEC- 556 validator?", July 2012, . 559 [Netalyzr] 560 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 561 "Implications of Netalyzr's DNS Measurements", Securing 562 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 563 2011, . 566 [Unbound-Configuration] 567 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 568 2010, . 571 Appendix A. Configuration Examples 573 The section contains example configurations to achieve Negative Trust 574 Anchor functionality for the zone foo.example.com. 576 Please note: These are simply examples - nameserver operators are 577 expected to test and understand the implications of these operations. 579 A.1. NLNet Labs Unbound 581 Unbound lets us simply disable validation checking for a specific 582 zone. See: [ TODO(WK): Make this a "real" reference ] 585 server: 586 domain-insecure: "foo.example.com" 588 A.2. ISC BIND 590 Use the "rndc" command: 592 nta -dump 593 List all negative trust anchors. 594 nta [-lifetime duration] [-force] domain [view] 595 Set a negative trust anchor, disabling DNSSEC validation 596 for the given domain. 597 Using -lifetime specifies the duration of the NTA, up 598 to one week. The default is one hour. 599 Using -force prevents the NTA from expiring before its 600 full lifetime, even if the domain can validate sooner. 601 nta -remove domain [view] 602 Remove a negative trust anchor, re-enabling validation 603 for the given domain. 605 A.3. Nominum Vantio 607 ** 609 *negative-trust-anchors* 611 _Format_: name 613 _Command Channel_: view.update name=world negative-trust- 614 anchors=(foo.example.com) 616 _Command Channel_: resolver.update name=res1 negative-trust- 617 anchors=(foo.example.com) 619 *Description*: Disables DNSSEC validation for a domain, even if the 620 domain is under an existing security root. 622 Appendix B. Document Change Log 624 [RFC Editor: This section is to be removed before publication] 626 Ind-07 - WG-00: 628 o Simply updated name to reflect WG doc. 630 WG-00 to WG-01: 632 o Stole chunks of text from Ed Lewis' mailing list "tirade" :-) 634 o New rndc usage text from Evan. 636 o Deleted the (already resolved) open issues from Appendix C, moved 637 the unresolved issues into github, resolved them! 639 o Clarification that automated removal is best removal method, and 640 how to implement (Evan Hunt) 642 o Clarify that an NTA is not a RR (Rick Lamb) 644 o Grammar fixes. 646 -01 to -02 648 o Gah! I forgot to run spell check. And I type like a chimpanzee 649 with bad hand-eye coordination... 651 Individual-00: First version published as an individual draft. 653 Individual-01: Fixed minor typos and grammatical nits. Closed all 654 open editorial items. 656 Individual-02: Simple date change to keep doc from expiring. 657 Substantive updates planned. 659 Individual-03: Changes to address feedback from Paul Vixie, by adding 660 a new section "Limited Time and Scope of Use". Changes to address 661 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 662 new section "Intentionally Broken Domains" and added two related 663 references. Added text to address the need for manual investigation, 664 as suggested by Patrik Falstrom. Added a suggestion on notification 665 as suggested by Marc Lampo. Made several additions and changes 666 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 667 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 669 Individual-04: Moved the section defining a NTA forward, and added 670 new text to the Abstract and Introduction per feedback from Paul 671 Hoffman. 673 Individual-05: Incorporated feedback from the DNSOP WG list received 674 on 2/17/13 and 2/18/13. This is likely the final version before the 675 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 676 per March Davids. 678 Individual-06: Added more OPEN issues to continue tracking WG 679 discussion. No changes in the main document - just expanded issue 680 tracking. 682 Individual-07: Refresh document - needs revision and rework before 683 IETF-91. Planning to add more contributors. 685 o Using github issue tracker - go see https://github.com/wkumari/ 686 draft-livingood-dnsop-negative-trust-anchors for more details. 688 o A bunch of readability improvments. 690 o Issue: Notify the domain owner of the validation failure - 691 resolved. 693 o Issue: Make the NTA as specific as possible - resolved. 695 Authors' Addresses 697 Paul Ebersman 698 Comcast 699 One Comcast Center 700 1701 John F. Kennedy Boulevard 701 Philadelphia, PA 19103 702 US 704 Email: ebersman-ietf@dragon.net 706 Chris Griffiths 707 Dyn 708 150 Dow Street 709 Tower Two 710 Manchester, NH 03101 711 US 713 Email: cgriffiths@gmail.com 714 URI: http://www.dyn.com 715 Warren Kumari 716 Google 717 1600 Amphitheatre Parkway 718 Mountain View, CA 94043 719 US 721 Email: warren@kumari.net 722 URI: http://www.google.com 724 Jason Livingood 725 Comcast 726 One Comcast Center 727 1701 John F. Kennedy Boulevard 728 Philadelphia, PA 19103 729 US 731 Email: jason_livingood@cable.comcast.com 732 URI: http://www.comcast.com 734 Ralf Weber 735 Nominum 737 Email: Ralf.Weber@nominum.com 738 URI: http://www.nominum.com