idnits 2.17.1 draft-ietf-dnsop-negative-trust-anchors-09.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 221: '...d in the operation of DNS servers MUST...' RFC 2119 keyword, line 262: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 263: '... Implementors SHOULD allow the opera...' RFC 2119 keyword, line 268: '...ive Trust Anchor MUST NOT be automatic...' RFC 2119 keyword, line 270: '...ive Trust Anchor SHOULD be used only i...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2015) is 3273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 609, but not defined Summary: 1 error (**), 0 flaws (~~), 2 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: November 13, 2015 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 May 12, 2015 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-ietf-dnsop-negative-trust-anchors-09 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 November 13, 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 and motivation . . . . . . . . . . . . . . . . . 3 67 1.1. Definition of a Negative Trust Anchor . . . . . . . . . . 3 68 1.2. Domain Validation Failures . . . . . . . . . . . . . . . 4 69 1.3. End User Reaction . . . . . . . . . . . . . . . . . . . . 4 70 1.4. Switching to a Non-Validating Resolver is Not Recommended 5 71 2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5 72 3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 73 3.1. Alerting Users to NTA Use . . . . . . . . . . . . . . . . 7 74 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 75 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 76 6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 77 7. Discovering broken domains . . . . . . . . . . . . . . . . . 9 78 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Security Considerations . . . . . . . . . . . . . . . . . 11 80 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11 81 8.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 13 87 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13 88 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13 89 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 14 90 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction and motivation 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 It is worth noting the following text from [RFC4033] - "In the final 127 analysis, however, authenticating both DNS keys and data is a matter 128 of local policy, which may extend or even override the protocol 129 extensions defined in this document set." A responsibility (one of 130 many) of a caching server operator is to "protect the integrity of 131 the cache." 133 1.1. Definition of a Negative Trust Anchor 135 Trust Anchors are defined in [RFC5914]. A trust anchor should be 136 used by a validating caching resolver as a starting point for 137 building the authentication chain for a signed DNS response. By way 138 of analogy, negative trust anchors stop validation of the 139 authentication chain. Instead, the validator treats any upstream 140 responses as if the zone is unsigned and does not set the AD bit in 141 responses it sends to clients. Note that this is a behavior, and not 142 a separate resource record. This Negative Trust Anchor can 143 potentially be implemented at any level within the chain of trust and 144 would stop validation from that point in the chain down. Validation 145 starts again if there is a positive trust anchor further down in the 146 chain. For example, if there is a NTA at example.com, and a positive 147 trust anchor at foo.bar.example.com, then validation resumes for 148 foo.bar.example.com and anything below it. 150 1.2. Domain Validation Failures 152 A domain name can fail validation for two general reasons: a 153 legitimate security failure such as due to an attack or compromise of 154 some sort, or as a result of misconfiguration on the part of an 155 domain administrator. As domains transition to DNSSEC, the most 156 common reason for a validation failure has been misconfiguration. 157 Thus, domain administrators should be sure to read [RFC6781] in full. 158 They should also pay special attention to Section 4.2, pertaining to 159 key rollovers, which appear to be the cause of many recent validation 160 failures. 162 It is also possible that some DNSSEC validation failures could arise 163 due to differences in how different software developers interpret 164 DNSSEC standards and/or how those developers choose to implement 165 support for DNSSEC. For example, it is conceivable that a domain may 166 be DNSSEC signed properly, and one vendor's DNS recursive resolvers 167 will validate the domain but other vendors' software may fail to 168 validate the domain. 170 1.3. End User Reaction 172 End users generally do not know of, understand, or care about the 173 resolution process that causes connections to happen. This is by 174 design: the point of the DNS is to insulate users from having to 175 remember IP addresses through a friendlier way of naming systems. It 176 follows from this that end users do not, and should not, be expected 177 to know about DNSSEC, validation, or anything of the sort. As a 178 result, end users may misinterpret the failure to reach a domain due 179 to DNSSEC-related misconfiguration . They may (incorrectly) assume 180 that their ISP is purposely blocking access to the domain or that it 181 is a performance failure on the part of their ISP (especially of the 182 ISP's DNS servers). They may contact their ISP to complain, which 183 will incur cost for their ISP. In addition, they may use online 184 tools and sites to complain of this problem, such as via a blog, web 185 forum, or social media site, which may lead to dissatisfaction on the 186 part of other end users or general criticism of an ISP or operator of 187 a DNS recursive resolver. 189 As end users publicize these failures, others may recommend they 190 switch from security-aware DNS resolvers to resolvers not performing 191 DNSSEC validation. This is a shame since the ISP or other DNS 192 recursive resolver operator is actually doing exactly what they are 193 supposed to do in failing to resolve a domain name; this is the 194 expected result when a domain can no longer be validated and it 195 protects end users from a potential security threat. Use of a 196 Negative Trust Anchor would allow the ISP to specifically remedy the 197 failure to reach that domain, without compromising security for other 198 sites. This would result in a satisfied end user, with minimal 199 impact to the ISP, while maintaining the security of DNSSEC for 200 correctly maintained domains. 202 1.4. Switching to a Non-Validating Resolver is Not Recommended 204 As noted in Section 1.3, some people may consider switching to an 205 alternative, non-validating resolver themselves, or may recommend 206 that others do so. But if a domain fails DNSSEC validation and is 207 inaccessible, this could very well be due to a security-related 208 issue. In order to be as safe and secure as possible, end users 209 should not change to DNS servers that do not perform DNSSEC 210 validation as a workaround, and people should not recommend that 211 others do so either. Domains that fail DNSSEC for legitimate reasons 212 (versus misconfiguration) may be in control of hackers or there could 213 be other significant security issues with the domain. 215 Thus, switching to a non-validating resolver to restore access to a 216 domain that fails DNSSEC validation is not a recommended practice, is 217 bad advice to others, is potentially harmful to end user security. 219 2. Use of a Negative Trust Anchor 221 Technical personnel trained in the operation of DNS servers MUST 222 confirm that a failure is due to misconfiguration, as a similar 223 breakage could have occurred if an attacker gained access to a 224 domain's authoritative servers and modified those records or had the 225 domain pointed to their own rogue authoritative servers. They should 226 also confirm that the domain is not intentionally broken, such as for 227 testing purposes as noted in Section 6. Finally, they should make a 228 reasonable attempt to contact the domain owner of the misconfigured 229 zone, preferably prior to implementing the Negative Trust Anchor. 230 Involving trained technical personnel is costly, but operational 231 experience suggests that this is a very rare event, usually on the 232 order of once per quarter (or even less). 234 It is important for the resolver operator to confirm that the domain 235 is still under the ownership / control of the legitimate owner of the 236 domain in order to ensure that disabling validation for a specific 237 domain does not direct users to an address under an attacker's 238 control. Contacting the domain owner and telling them the DNSSEC 239 records that the resolver operator is seeing allows the resolver 240 operator to determine if the issue is a DNSSEC misconfiguration or an 241 attack. 243 In the case of a validation failure due to misconfiguration of a TLD 244 or popular domain name (such as a top 100 website), content or 245 services in the affected TLD or domain could be inaccessible for a 246 large number of users. In such cases, it may be appropriate to use a 247 Negative Trust Anchor as soon as the misconfiguration is confirmed. 248 An example of a list of "top N" websites is the "Alexa Top 500 Sites 249 on the Web" [Alexa], , or a list of the of the most-accessed names in 250 the resolver's cache. 252 Once a domain has been confirmed to fail DNSSEC validation due to a 253 DNSSEC-related misconfiguration, an ISP or other DNS recursive 254 resolver operator may elect to use a Negative Trust Anchor for that 255 domain or sub-domain. This instructs their DNS recursive resolver to 256 temporarily NOT perform DNSSEC validation at or in the misconfigured 257 domain. This immediately restores access to the domain for end users 258 while the domain's administrator corrects the misconfiguration(s). 259 It does not and should not involve turning off validation more 260 broadly. 262 A Negative Trust Anchor MUST only be used for a limited duration. 263 Implementors SHOULD allow the operator using the Negative Trust 264 Anchor to set an end time and date associated with any Negative Trust 265 Anchor. Optimally, this time and date is set in a DNS recursive 266 resolver's configuration, though in the short-term this may also be 267 achieved via other systems or supporting processes. Use of a 268 Negative Trust Anchor MUST NOT be automatic. 270 Finally, a Negative Trust Anchor SHOULD be used only in a specific 271 domain or sub-domain and MUST NOT affect validation of other names up 272 the authentication chain. For example, a Negative Trust Anchor for 273 zone1.example.com would affect only names at or below 274 zone1.example.com, and validation would still be performed on 275 example.com, .com, and the root ("."). This Negative Trust Anchor 276 also SHOULD NOT affect names in another branch of the tree (such as 277 example.net). In another example, a Negative Trust Anchor for 278 example.com would affect only names within example.com, and 279 validation would still be performed on .com, and the root ("."). In 280 this scenario, if there is a (probably manually configured) trust 281 anchor for zone1.example.com, validation would be performed for 282 zone1.example.com and subdomains of zone1.example.com. 284 3. Managing Negative Trust Anchors 286 While Negative Trust Anchors have proven useful during the early 287 stages of DNSSEC adoption, domain owners are ultimately responsible 288 for managing and ensuring their DNS records are configured correctly. 290 Most current implementations of DNS validating resolvers currently 291 follow [RFC4033] on configuring a Trust Anchor using either a public 292 key as in a DNSKEY RR or a hash of a public key as in a DS RR. 294 Different DNS validators may have different configuration names for a 295 Negative Trust Anchor. For examples see Appendix A. 297 An NTA placed at a node where there is a configured positive trust 298 anchor MUST take precendence over that trust anchor, effectively 299 disabling it. Implementations SHOULD issue a warning or 300 informational message when this occurs, so that operators are not 301 surprised when this happens. 303 3.1. Alerting Users to NTA Use 305 End users of a DNS recursive resolver or other people may wonder why 306 a domain that fails DNSSEC validation resolves with a supposedly 307 validating resolver. As a result, implementors should consider 308 transparently disclosing those Negative Trust Anchors which are 309 currently in place or were in place in the past, such as on a website 310 [Disclosure-Example]. 312 This is particularly important since there is currently no special 313 DNS query response code that could indicate to end users or 314 applications that a Negative Trust Anchor is in place. Such 315 disclosures should optimally include both the data and time that the 316 Negative Trust Anchor was put in place and when it was removed. 318 4. Removal of a Negative Trust Anchor 320 As explored in Section 8.1, using an NTA once the zone correctly 321 validates can have security considerations. It is therefore 322 RECOMMENDED that NTA implementors SHOULD periodically attempt to 323 validate the domain in question, for the period of time that the 324 Negative Trust Anchor is in place, until such validation is again 325 successful. NTAs MUST expire automatically when their configured 326 lifetime ends. The lifetime MUST NOT exceed a week. Before removing 327 the Negative Trust Anchor, all authoritative resolvers listed in the 328 zone should be checked (due to anycast and load balancers it may not 329 be possible to check all instances). 331 Once all testing succeeds, a Negative Trust Anchor should be removed 332 as soon as is reasonably possible. One possible method to 333 automatically determine when the NTA can be removed is to send a 334 periodic query for type SOA at the NTA node; if it gets a response 335 that it can validate (whether the response was an actual SOA answer 336 or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is 337 presumed no longer to be necessary and is removed. Implementations 338 SHOULD, by default, perform this operation. Note that under some 339 circumstances this is undesirable behavior (for example, if 340 www.example.com has a bad signature, but example.com/SOA is fine) and 341 so implementations may wish to allow the operator to override this 342 spot-check / behavior. 344 When removing the NTA, the implementation SHOULD remove all cached 345 entries at and below the NTA node. 347 5. Comparison to Other DNS Misconfigurations 349 Domain administrators are ultimately responsible for managing and 350 ensuring their DNS records are configured correctly. ISPs or other 351 DNS recursive resolver operators cannot and should not correct 352 misconfigured A, CNAME, MX, or other resource records of domains for 353 which they are not authoritative. Expecting non-authoritative 354 entities to protect domain administrators from any misconfiguration 355 of resource records is therefore unrealistic and unreasonable, and in 356 the long-term is harmful to the delegated design of the DNS and could 357 lead to extensive operational instability and/or variation. 359 With DNSSEC breakage, it is often possible to tell that there is a 360 misconfiguration by looking at the data and not needing to guess what 361 it should have been. 363 6. Intentionally Broken Domains 365 Some domains, such as dnssec-failed.org, have been intentionally 366 broken for testing purposes 367 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 368 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 369 If an end user is querying a validating DNS recursive resolver, then 370 this or other similarly intentionally broken domains should fail to 371 resolve and should result in a "Server Failure" error (RCODE 2, also 372 known as 'SERVFAIL'). If such a domain resolved successfully, then 373 it is a sign that the DNS recursive resolver is not fully validating. 375 Organizations that utilize Negative Trust Anchors should not add a 376 Negative Trust Anchor for any intentionally broken domain. Such 377 additions are prevented by the requirement that the operator attempt 378 to contact the administrators for the zone that has broken DNSSEC. 380 Organizations operating an intentionally broken domain may wish to 381 consider adding a TXT record for the domain to the effect of "This 382 domain is purposely DNSSEC broken for testing purposes". 384 7. Discovering broken domains 386 Discovering that a domain is DNSSEC broken as result of an operator 387 error instead of an attack is not trivial, and the examples here 388 should be vetted by an experienced professional before taking the 389 decision on implementing an negative trust anchor. 391 One of the key thing to look for when looking at a DNSSEC broken 392 domain is consistency and history. It therefore is good if you have 393 the ability to look at the server's DNS traffic over a long period of 394 time or have a database that stores DNS names associated answers 395 (this is often referred to as a "passive DNS database"). Another 396 invaluable tool is dnsviz (http://www.dnsivz.net) which also stores 397 DNSSEC related data historically. The drawback here is that you need 398 to have it test the domain before the incident occurs. 400 The first and easiest thing to check is if the failure of the domain 401 is consistent across different software implementations. If not, you 402 want to inform the vendor where it fails so that the vendor can look 403 more deeply into the issue. 405 The next thing is to figure out what the actual failure mode is. 406 There are several tools to do this, an incomplete list includes: 408 o DNSViz (http://dnsviz.net) 410 o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) 412 o iis.se DNS check (http://dnscheck.iis.se) 414 most of these tools are open source and can be installed locally. 415 However, using the tools over the Internet has the advantage of 416 providing visibility from a different point. 418 Once you figure out what the error is, you need to check if it shows 419 consistently around the world and from all authoritative servers. 420 Use DNS Tools (dig) or DNS looking glasses to verify this. An error 421 that is consistently the same is more likely to be operator caused 422 than an attack. Also if the output from the authoritative server is 423 consistently different from the resolvers output this hints to an 424 attack rather then an error, unless there is EDNS0 client subnet 425 (draft-ietf-dnsop-edns-client-subnet) applied to the domain. 427 A last check is to look at the actual DNS data. Is the result of the 428 query still the same or has it changed? While a lot of DNSSEC errors 429 occur on events that change DNSSEC data, the actual record someone 430 wants to go to often stays the same. If the data is the same, this 431 is an indication (not a guarantee) that the error is operator caused. 432 Keep in mind that with DNS being used to globally balance traffic the 433 data associated to a name might be different in different parts of 434 the Internet. 436 Here are some examples of common DNSSEC failures that have been seen 437 as operator signing errors on the Internet: 439 o RRSIG timing issue. Each signature has an inception time and 440 expiry time, between which it is valid. Letting this time expire 441 without creating a new signature is one of the most common DNSSEC 442 errors. To a lesser extent, this also occurs if signatures were 443 made active before the inception time. For all of these errors 444 your primary check is to check on the data. Signature expiration 445 is also about the only error we see on actual data (like 446 www.example.com). All other errors are more or less related to 447 dealing with the chain of trust established by DS records in the 448 parent zone and DNSKEYs in the child zones. These mostly occur 449 during key rollovers, but are not limited to that. 451 o DNSKEYs in child zone don't match the DS record in the parent 452 zone. There is a big variation of this that can happen at any 453 point in the key lifecycle. DNSViz is the best tools to show 454 problems in the chain. If you debug yourself use dig +multiline 455 so that you can see the key id of a DNSKEY. Common Variations of 456 this can be: 458 * DS pointing to a non existent key in the child zone. Questions 459 for consideration here include: Has there ever been a key (and, 460 if so, was it used)? Has there been a recent change in the 461 DNSKEY RRSet (indicating a key rollover)? Has the actual data 462 in the zone changed? Is the zone DNSSEC signed at all and has 463 it been in the past? 465 * DS pointing to an existent key, but no signatures are made with 466 the key. The checks above should be done, with the addition of 467 checking if another key in the DNSKEY RRSet is now used to sign 468 the records. 470 * Data in DS or DNSKEY doesn't match the other. This is more 471 common in initial setup when there was a copy and paste error. 472 Again checking history on data is the best you can do there. 474 All of the above is just a starting point for consideration when 475 deciding whether or not to deploy a trust anchor. It is not possible 476 to provide a simple checklist to run through to determine whether a 477 domain is broken because of an attack or an operator error. 479 8. Other Considerations 481 8.1. Security Considerations 483 End to end DNSSEC validation will be disabled during the time that a 484 Negative Trust Anchor is used. In addition, the Negative Trust 485 Anchor may be in place after the point in time when the DNS 486 misconfiguration that caused validation to break has been fixed. 487 Thus, there may be a gap between when a domain has been re-secured 488 and when a Negative Trust Anchor is removed. In addition, a Negative 489 Trust Anchor may be put in place by DNS recursive resolver operators 490 without the knowledge of the authoritative domain administrator for a 491 given domain name. However, attempts SHOULD be made to contact and 492 inform the domain administrator prior to putting the NTA in place. 494 One side effect of implementing an NTA is that it may break client 495 applications that assume that a domain is signed and expect an AD bit 496 in the response. It is expected that many application that require 497 DNSSEC for a domain will perform their own validation, and so this 498 should not be a major issue. 500 8.2. Privacy Considerations 502 There are no privacy considerations in this document. 504 8.3. IANA Considerations 506 There are no IANA considerations in this document. 508 9. Acknowledgements 510 Several people made contributions of text to this document and/or 511 played an important role in the development and evolution of this 512 document. This in some cases included performing a detailed review 513 of this document and then providing feedback and constructive 514 criticism for future revisions, or engaging in a healthy debate over 515 the subject of the document. All of this was helpful and therefore 516 the following individuals merit acknowledgement: Joe Abley,John 517 Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, 518 Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes 519 Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc 520 Lampo, Scott Rose, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik 521 Wallstrom, W.C.A. Wijngaards, Nick Weaver 522 Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided 523 especially large amounts of text and / or detailed review. 525 10. References 527 10.1. Normative References 529 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 530 Rose, "DNS Security Introduction and Requirements", RFC 531 4033, March 2005. 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 10.2. Informative References 542 [Alexa] Alexa, an Amazon.com Company, "Alexa "The top 500 sites on 543 the web. "", , May 2015, . 545 [Disclosure-Example] 546 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 547 Comcast , February 2013, 548 . 551 [Measuring-DNSSEC-Validation-of-Website-Visitors] 552 Mens, J., "Is my Web site being used via a DNSSEC- 553 validator?", July 2012, . 556 [Netalyzr] 557 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 558 "Implications of Netalyzr's DNS Measurements", Securing 559 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 560 2011, . 563 [Unound-Configuration] 564 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 565 2010, . 568 Appendix A. Configuration Examples 570 The section contains example configurations to achieve Negative Trust 571 Anchor functionality for the zone foo.example.com. 573 Note: These are simply examples - nameserver operators are expected 574 to test and understand the implications of these operations. Note 575 also that some of available implementations may not implement all 576 recommended functionality in this document. In that case it is 577 advisable to request the developer or vendor of the implementation to 578 support the missing feature, rather than start using the incomplete 579 implementation. 581 A.1. NLNet Labs Unbound 583 Unbound lets us simply disable validation checking for a specific 584 zone by adding configuration statements to unbound.conf: 586 server: 587 domain-insecure: "foo.example.com" 589 Using the 'unbound-control' command one can add and remove Negative 590 Trust Anchors without restarting the nameserver. 592 Using the "unbound-control" command: 593 list_insecure list domain-insecure zones 594 insecure_add zone add domain-insecure zone 595 insecure_remove zone remove domain-insecure zone 597 Items added with the "unbound-control" command are added to the 598 running server and are lost when the server is restarted. Items from 599 unbound.conf stay after restart. 601 For additional information see [Unound-Configuration] 603 A.2. ISC BIND 605 Use the "rndc" command: 607 nta -dump 608 List all negative trust anchors. 609 nta [-lifetime duration] [-force] domain [view] 610 Set a negative trust anchor, disabling DNSSEC validation 611 for the given domain. 612 Using -lifetime specifies the duration of the NTA, up 613 to one week. The default is one hour. 614 Using -force prevents the NTA from expiring before its 615 full lifetime, even if the domain can validate sooner. 616 nta -remove domain [view] 617 Remove a negative trust anchor, re-enabling validation 618 for the given domain. 620 A.3. Nominum Vantio 622 ** 624 *negative-trust-anchors* 626 _Format_: name 628 _Command Channel_: view.update name=world negative-trust- 629 anchors=(foo.example.com) 631 _Command Channel_: resolver.update name=res1 negative-trust- 632 anchors=(foo.example.com) 634 *Description*: Disables DNSSEC validation for a domain, even if the 635 domain is under an existing security root. 637 Appendix B. Document Change Log 639 [RFC Editor: This section is to be removed before publication] 641 -08 to -09 643 o Clarified that an NTA MUST take precedece over a positive, local 644 TA. 646 -07 to -08 648 o Added some cleanup from Paul Hoffman and Evan Hunt. 650 o Some better text on how to make Unbound do this, provided by 651 W.C.A. Wijngaards. 653 -06 to -07 654 o Addressed a large number of comments from Paul Hoffman, Scott Rose 655 and some more from Jinmei. 657 -05 to -06 659 o A bunch of comments from Tony Finch. 661 -04 to -05 663 o A large bunch of cleanups from Jinmei. Thanks! 665 o Also clarified that if there is an NTA at foo.bar.baz.example, and 666 a positive *trust anchor* at bar.baz.example, the most specific 667 wins. I'm not very happy with this text, any additional text 668 gratefully accepted... 670 -03 to -04: 672 o Addressed some comment from an email from Jinmei that I had 673 missed. Turns out others had made many of the same comments, and 674 so most had already been addressed. 676 -02 to -03: 678 o Included text from Ralph into Appendix B 680 o A bunch of comments from Andrew Sullivan ('[DNSOP] negative-trust- 681 anchors-02" - Mar 18th) 683 o Updated keywords 685 -01 to -02: 687 o Gah! I forgot to run spell check. And I type like a chimpanzee 688 with bad hand-eye coordination... 690 -00 to -01: 692 o Stole chunks of text from Ed Lewis' mailing list "tirade" :-) 694 o New rndc usage text from Evan. 696 o Deleted the (already resolved) open issues from Appendix C, moved 697 the unresolved issues into github, resolved them! 699 o Clarification that automated removal is best removal method, and 700 how to implement (Evan Hunt) 702 o Clarify that an NTA is not a RR (Rick Lamb) 704 o Grammar fixes. 706 Ind-07 - WG-00: 708 o Simply updated name to reflect WG doc. 710 Individual-00: First version published as an individual draft. 712 Individual-01: Fixed minor typos and grammatical nits. Closed all 713 open editorial items. 715 Individual-02: Simple date change to keep doc from expiring. 716 Substantive updates planned. 718 Individual-03: Changes to address feedback from Paul Vixie, by adding 719 a new section "Limited Time and Scope of Use". Changes to address 720 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 721 new section "Intentionally Broken Domains" and added two related 722 references. Added text to address the need for manual investigation, 723 as suggested by Patrik Falstrom. Added a suggestion on notification 724 as suggested by Marc Lampo. Made several additions and changes 725 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 726 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 728 Individual-04: Moved the section defining a NTA forward, and added 729 new text to the Abstract and Introduction per feedback from Paul 730 Hoffman. 732 Individual-05: Incorporated feedback from the DNSOP WG list received 733 on 2/17/13 and 2/18/13. This is likely the final version before the 734 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 735 per March Davids. 737 Individual-06: Added more OPEN issues to continue tracking WG 738 discussion. No changes in the main document - just expanded issue 739 tracking. 741 Individual-07: Refresh document - needs revision and rework before 742 IETF-91. Planning to add more contributors. 744 o Using github issue tracker - go see https://github.com/wkumari/ 745 draft-livingood-dnsop-negative-trust-anchors for more details. 747 o A bunch of readability improvments. 749 o Issue: Notify the domain owner of the validation failure - 750 resolved. 752 o Issue: Make the NTA as specific as possible - resolved. 754 Authors' Addresses 756 Paul Ebersman 757 Comcast 758 One Comcast Center 759 1701 John F. Kennedy Boulevard 760 Philadelphia, PA 19103 761 US 763 Email: ebersman-ietf@dragon.net 765 Chris Griffiths 767 Email: cgriffiths@gmail.com 769 Warren Kumari 770 Google 771 1600 Amphitheatre Parkway 772 Mountain View, CA 94043 773 US 775 Email: warren@kumari.net 776 URI: http://www.google.com 778 Jason Livingood 779 Comcast 780 One Comcast Center 781 1701 John F. Kennedy Boulevard 782 Philadelphia, PA 19103 783 US 785 Email: jason_livingood@cable.comcast.com 786 URI: http://www.comcast.com 788 Ralf Weber 789 Nominum 791 Email: Ralf.Weber@nominum.com 792 URI: http://www.nominum.com