idnits 2.17.1 draft-ietf-dnsop-negative-trust-anchors-11.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 267: '... A NTA MUST only be used for a limit...' RFC 2119 keyword, line 272: '... of an NTA MUST NOT be automatic....' RFC 2119 keyword, line 274: '... Finally, an NTA SHOULD be used only i...' RFC 2119 keyword, line 275: '... domain and MUST NOT affect validati...' RFC 2119 keyword, line 279: '... This NTA also SHOULD NOT affect nam...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2015) is 3181 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 619, 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: January 15, 2016 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 July 14, 2015 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-ietf-dnsop-negative-trust-anchors-11 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. This document defines Negative 23 Trust Anchors which can be used to mitigate DNSSEC validation 24 failures by disabling DNSSEC validation at specified domains. 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 January 15, 2016. 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. Motivations for Negative Trust Anchors . . . . . . . . . 4 69 1.2.1. Mitigating Domain Validation Failures . . . . . . . . 4 70 1.2.2. Improving End User Experience . . . . . . . . . . . . 4 71 1.2.3. Avoiding Switching to a Non-Validating Resolver . . . 5 72 2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5 73 2.1. Applicability of Negative Trust Anchors . . . . . . . . . 6 74 3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 75 3.1. Alerting Users to Negative Trust Anchor Use . . . . . . . 7 76 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 77 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 78 6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 79 7. Discovering broken domains . . . . . . . . . . . . . . . . . 9 80 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 13 88 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13 89 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13 90 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 14 91 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction and motivation 96 DNSSEC has now entered widespread deployment. However, the DNSSEC 97 signing tools and processes are less mature and reliable than those 98 for non-DNSSEC-related administration. As a result, operators of DNS 99 recursive resolvers, such as Internet Service Providers (ISPs), 100 occasionally observe domains incorrectly managing DNSSEC-related 101 resource records. This mismanagement triggers DNSSEC validation 102 failures, and then causes large numbers of end users to be unable to 103 reach a domain. Many end users tend to interpret this as a failure 104 of their ISP or resolver operator, and may switch to a non-validating 105 resolver or contact their ISP to complain, rather than seeing this as 106 a failure on the part of the domain they wanted to reach. Without 107 the techniques in this document, this pressure may cause the resolver 108 operator to disable (or simply not deploy) DNSSEC validation. 110 This document defines the Negative Trust Anchor (NTA), which can be 111 used during the transition to ubiquitous DNSSEC deployment. NTAs are 112 configured locally on a validating DNS recursive resolver to shield 113 end users from DNSSEC-related authoritative name server operational 114 errors. NTAs are intended to be temporary, and only implemented by 115 the organization requiring an NTA (and not distributed by any 116 organizations outside of the administrative boundary). Finally, NTAs 117 pertain only to DNSSEC and not to Public Key Infrastructures (PKI) 118 such as X.509. 120 Use of an NTA to temporarily disable DNSSEC validation for a specific 121 misconfigured domain name immediately restores access for end users. 122 This allows the domain's administrators to fix their 123 misconfiguration, while also allowing the organization using the NTA 124 to keep DNSSEC validation enabled and still reach the misconfigured 125 domain. 127 [ ED NOTE: Don't forget to insert 2119 boilerplate - not doing now, 128 to avoid messing up section numbers... ] 130 1.1. Definition of a Negative Trust Anchor 132 Trust Anchors are defined in [RFC5914]. A trust anchor is used by a 133 validating caching resolver as a starting point for building the 134 authentication chain for a signed DNS response. By way of analogy, 135 NTAs stop validation of the authentication chain. Instead, the 136 validator treats any upstream responses as if the zone is unsigned 137 and does not set the AD bit in responses it sends to clients. Note 138 that this is a behavior, and not a separate resource record. This 139 NTA can potentially be implemented at any level within the chain of 140 trust and would stop validation from that point in the chain down. 141 Validation starts again if there is a positive trust anchor further 142 down in the chain. For example, if there is an NTA at example.com, 143 and a positive trust anchor at foo.bar.example.com, then validation 144 resumes for foo.bar.example.com and anything below it. 146 1.2. Motivations for Negative Trust Anchors 148 1.2.1. Mitigating Domain Validation Failures 150 A domain name can fail validation for two general reasons: a 151 legitimate security failure such as due to an attack or compromise of 152 some sort, or as a result of misconfiguration on the part of a zone 153 administrator. As domains transition to DNSSEC, the most common 154 reason for a validation failure has been misconfiguration. Thus, 155 domain administrators should be sure to read [RFC6781] in full. They 156 should also pay special attention to Section 4.2, pertaining to key 157 rollovers, which appear to be the cause of many recent validation 158 failures. 160 It is also possible that some DNSSEC validation failures could arise 161 due to differences in how different software developers interpret 162 DNSSEC standards and/or how those developers choose to implement 163 support for DNSSEC. For example, it is conceivable that a domain may 164 be DNSSEC signed properly, and one vendor's DNS recursive resolvers 165 will validate the domain but other vendors' software may fail to 166 validate the domain. 168 1.2.2. Improving End User Experience 170 End users generally do not know of, understand, or care about the 171 resolution process that causes connections to happen. This is by 172 design: the point of the DNS is to insulate users from having to 173 remember IP addresses through a friendlier way of naming systems. It 174 follows from this that end users do not, and should not, be expected 175 to know about DNSSEC, validation, or anything of the sort. As a 176 result, end users may misinterpret the failure to reach a domain due 177 to DNSSEC-related misconfiguration . They may (incorrectly) assume 178 that their ISP is purposely blocking access to the domain or that it 179 is a performance failure on the part of their ISP (especially of the 180 ISP's DNS servers). They may contact their ISP to complain, which 181 will incur cost for their ISP. In addition, they may use online 182 tools and sites to complain of this problem, such as via a blog, web 183 forum, or social media site, which may lead to dissatisfaction on the 184 part of other end users or general criticism of an ISP or operator of 185 a DNS recursive resolver. 187 As end users publicize these failures, others may recommend they 188 switch from security-aware DNS resolvers to resolvers not performing 189 DNSSEC validation. This is a shame since the ISP or other DNS 190 recursive resolver operator is actually doing exactly what they are 191 supposed to do in failing to resolve a domain name; this is the 192 expected result when a domain can no longer be validated and it 193 protects end users from a potential security threat. Use of an NTA 194 would allow the ISP to specifically remedy the failure to reach that 195 domain, without compromising security for other sites. This would 196 result in a satisfied end user, with minimal impact to the ISP, while 197 maintaining the security of DNSSEC for correctly maintained domains. 199 It is worth noting the following text from [RFC4033] - "In the final 200 analysis, however, authenticating both DNS keys and data is a matter 201 of local policy, which may extend or even override the protocol 202 extensions defined in this document set." A responsibility (one of 203 many) of a caching server operator is to "protect the integrity of 204 the cache." 206 1.2.3. Avoiding Switching to a Non-Validating Resolver 208 As noted in Section 1.2.2, some people may consider switching to an 209 alternative, non-validating resolver themselves, or may recommend 210 that others do so. But if a domain fails DNSSEC validation and is 211 inaccessible, this could very well be due to a security-related 212 issue. In order to be as safe and secure as possible, end users 213 should not change to DNS servers that do not perform DNSSEC 214 validation as a workaround, and people should not recommend that 215 others do so either. Domains that fail DNSSEC for legitimate reasons 216 (versus misconfiguration) may be in control of hackers or there could 217 be other significant security issues with the domain. 219 Thus, switching to a non-validating resolver to restore access to a 220 domain that fails DNSSEC validation is not a recommended practice, is 221 bad advice to others, is potentially harmful to end user security. 223 2. Use of a Negative Trust Anchor 225 Technical personnel trained in the operation of DNS servers must 226 confirm that a DNSSEC validation failure is due to misconfiguration, 227 as a similar breakage could have occurred if an attacker gained 228 access to a domain's authoritative servers and modified those records 229 or had the domain pointed to their own rogue authoritative servers. 230 They should also confirm that the domain is not intentionally broken, 231 such as for testing purposes as noted in Section 6. Finally, they 232 should make a reasonable attempt to contact the domain owner of the 233 misconfigured zone, preferably prior to implementing the NTA. 234 Involving trained technical personnel is costly, but operational 235 experience suggests that this is a very rare event, usually on the 236 order of once per quarter (or even less). 238 It is important for the resolver operator to confirm that the domain 239 is still under the ownership / control of the legitimate owner of the 240 domain in order to ensure that disabling validation for a specific 241 domain does not direct users to an address under an attacker's 242 control. Contacting the domain owner and telling them the DNSSEC 243 records that the resolver operator is seeing allows the resolver 244 operator to determine if the issue is a DNSSEC misconfiguration or an 245 attack. 247 In the case of a validation failure due to misconfiguration of a TLD 248 or popular domain name (such as a top 100 website), content or 249 services in the affected TLD or domain could be inaccessible for a 250 large number of users. In such cases, it may be appropriate to use 251 an NTA as soon as the misconfiguration is confirmed. An example of a 252 list of "top N" websites is the "Alexa Top 500 Sites on the Web" 253 [Alexa], , or a list of the of the most-accessed names in the 254 resolver's cache. 256 Once a domain has been confirmed to fail DNSSEC validation due to a 257 DNSSEC-related misconfiguration, an ISP or other DNS recursive 258 resolver operator may elect to use an NTA for that domain or sub- 259 domain. This instructs their DNS recursive resolver to temporarily 260 NOT perform DNSSEC validation at or in the misconfigured domain. 261 This immediately restores access to the domain for end users while 262 the domain's administrator corrects the misconfiguration(s). It does 263 not and should not involve turning off validation more broadly. 265 2.1. Applicability of Negative Trust Anchors 267 A NTA MUST only be used for a limited duration. Implementors SHOULD 268 allow the operator using the NTA to set an end time and date 269 associated with any NTA. Optimally, this time and date is set in a 270 DNS recursive resolver's configuration, though in the short-term this 271 may also be achieved via other systems or supporting processes. Use 272 of an NTA MUST NOT be automatic. 274 Finally, an NTA SHOULD be used only in a specific domain or sub- 275 domain and MUST NOT affect validation of other names up the 276 authentication chain. For example, an NTA for zone1.example.com 277 would affect only names at or below zone1.example.com, and validation 278 would still be performed on example.com, .com, and the root ("."). 279 This NTA also SHOULD NOT affect names in another branch of the tree 280 (such as example.net). In another example, an NTA for example.com 281 would affect only names within example.com, and validation would 282 still be performed on .com, and the root ("."). In this scenario, if 283 there is a (probably manually configured) trust anchor for 284 zone1.example.com, validation would be performed for 285 zone1.example.com and subdomains of zone1.example.com. 287 3. Managing Negative Trust Anchors 289 While NTAs have proven useful during the early stages of DNSSEC 290 adoption, domain owners are ultimately responsible for managing and 291 ensuring their DNS records are configured correctly. 293 Most current implementations of DNS validating resolvers currently 294 follow [RFC4033] on configuring a Trust Anchor using either a public 295 key as in a DNSKEY RR or a hash of a public key as in a DS RR. 297 Different DNS validators may have different configuration names for 298 an NTA. For examples see Appendix A. 300 An NTA placed at a node where there is a configured positive trust 301 anchor MUST take precedence over that trust anchor, effectively 302 disabling it. Implementations MAY issue a warning or informational 303 message when this occurs, so that operators are not surprised when 304 this happens. 306 3.1. Alerting Users to Negative Trust Anchor Use 308 End users of a DNS recursive resolver or other people may wonder why 309 a domain that fails DNSSEC validation resolves with a supposedly 310 validating resolver. As a result, implementors should consider 311 transparently disclosing those NTAs which are currently in place or 312 were in place in the past, such as on a website [Disclosure-Example]. 314 This is particularly important since there is currently no special 315 DNS query response code that could indicate to end users or 316 applications that an NTA is in place. Such disclosures should 317 optimally include both the data and time that the NTA was put in 318 place and when it was removed. 320 4. Removal of a Negative Trust Anchor 322 As explored in Section 10, using an NTA once the zone correctly 323 validates can have security considerations. It is therefore 324 RECOMMENDED that NTA implementors should periodically attempt to 325 validate the domain in question, for the period of time that the NTA 326 is in place, until such validation is again successful. NTAs MUST 327 expire automatically when their configured lifetime ends. The 328 lifetime SHOULD NOT exceed a week. There is limited experience with 329 what this value should be, but at least one large vendor has 330 documented customer feedback suggesting that a week is reasonable 331 based on expectations of how long failures take to fix or to be 332 forgotten. Operational experience may further refine these 333 expectations. 335 Before removing the NTA, all authoritative resolvers listed in the 336 zone should be checked (due to anycast and load balancers it may not 337 be possible to check all instances). 339 Once all testing succeeds, an NTA should be removed as soon as is 340 reasonably possible. One possible method to automatically determine 341 when the NTA can be removed is to send a periodic query for type SOA 342 at the NTA node; if it gets a response that it can validate (whether 343 the response was an actual SOA answer or a NOERROR/NODATA with 344 appropriate NSEC/NSEC3 records), the NTA is presumed no longer to be 345 necessary and is removed. Implementations SHOULD, by default, 346 perform this operation. Note that under some circumstances this is 347 undesirable behavior (for example, if www.example.com has a bad 348 signature, but example.com/SOA is fine) and so implementations may 349 wish to allow the operator to override this spot-check / behavior. 351 When removing the NTA, the implementation SHOULD remove all cached 352 entries at and below the NTA node. 354 5. Comparison to Other DNS Misconfigurations 356 Domain administrators are ultimately responsible for managing and 357 ensuring their DNS records are configured correctly. ISPs or other 358 DNS recursive resolver operators cannot and should not correct 359 misconfigured A, CNAME, MX, or other resource records of domains for 360 which they are not authoritative. Expecting non-authoritative 361 entities to protect domain administrators from any misconfiguration 362 of resource records is therefore unrealistic and unreasonable, and in 363 the long-term is harmful to the delegated design of the DNS and could 364 lead to extensive operational instability and/or variation. 366 With DNSSEC breakage, it is often possible to tell that there is a 367 misconfiguration by looking at the data and not needing to guess what 368 it should have been. 370 6. Intentionally Broken Domains 372 Some domains, such as dnssec-failed.org, have been intentionally 373 broken for testing purposes 374 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 375 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 376 If an end user is querying a validating DNS recursive resolver, then 377 this or other similarly intentionally broken domains should fail to 378 resolve and should result in a "Server Failure" error (RCODE 2, also 379 known as 'SERVFAIL'). If such a domain resolved successfully, then 380 it is a sign that the DNS recursive resolver is not fully validating. 382 Organizations that utilize NTAs should not add an NTA for any 383 intentionally broken domain. Such additions are prevented by the 384 requirement that the operator attempt to contact the administrators 385 for the zone that has broken DNSSEC. 387 Organizations operating an intentionally broken domain may wish to 388 consider adding a TXT record for the domain to the effect of "This 389 domain is purposely DNSSEC broken for testing purposes". 391 7. Discovering broken domains 393 Discovering that a domain is DNSSEC broken as result of an operator 394 error instead of an attack is not trivial, and the examples here 395 should be vetted by an experienced professional before taking the 396 decision on implementing an NTA. 398 One of the key thing to look for when looking at a DNSSEC broken 399 domain is consistency and history. It therefore is good if you have 400 the ability to look at the server's DNS traffic over a long period of 401 time or have a database that stores DNS names associated answers 402 (this is often referred to as a "passive DNS database"). Another 403 invaluable tool is dnsviz (http://www.dnsivz.net) which also stores 404 DNSSEC related data historically. The drawback here is that you need 405 to have it test the domain before the incident occurs. 407 The first and easiest thing to check is if the failure of the domain 408 is consistent across different software implementations. If not, you 409 want to inform the vendor where it fails so that the vendor can look 410 more deeply into the issue. 412 The next thing is to figure out what the actual failure mode is. At 413 the time of this writing are several tools to do this, including: 415 o DNSViz (http://dnsviz.net) 417 o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) 419 o zonemaster (http://www.zonemaster.fr, https://github.com/dotse/ 420 zonemaster) 422 most of these tools are open source and can be installed locally. 423 However, using the tools over the Internet has the advantage of 424 providing visibility from a different point. This is an incomplete 425 list, and it is expected that additional tools will be developed over 426 time to aid in troubleshooting DNSSEC issues. 428 Once you figure out what the error is, you need to check if it shows 429 consistently around the world and from all authoritative servers. 431 Use DNS Tools (dig) or DNS looking glasses to verify this. An error 432 that is consistently the same is more likely to be operator caused 433 than an attack. Also if the output from the authoritative server is 434 consistently different from the resolvers output this hints to an 435 attack rather then an error, unless there is EDNS0 client subnet 436 (draft-ietf-dnsop-edns-client-subnet) applied to the domain. 438 A last check is to look at the actual DNS data. Is the result of the 439 query still the same or has it changed? While a lot of DNSSEC errors 440 occur on events that change DNSSEC data, the actual record someone 441 wants to go to often stays the same. If the data is the same, this 442 is an indication (not a guarantee) that the error is operator caused. 443 Keep in mind that with DNS being used to globally balance traffic the 444 data associated to a name might be different in different parts of 445 the Internet. 447 Here are some examples of common DNSSEC failures that have been seen 448 as operator signing errors on the Internet: 450 o RRSIG timing issue. Each signature has an inception time and 451 expiry time, between which it is valid. Letting this time expire 452 without creating a new signature is one of the most common DNSSEC 453 errors. To a lesser extent, this also occurs if signatures were 454 made active before the inception time. For all of these errors 455 your primary check is to check on the data. Signature expiration 456 is also about the only error we see on actual data (like 457 www.example.com). All other errors are more or less related to 458 dealing with the chain of trust established by DS records in the 459 parent zone and DNSKEYs in the child zones. These mostly occur 460 during key rollovers, but are not limited to that. 462 o DNSKEYs in child zone don't match the DS record in the parent 463 zone. There is a big variation of this that can happen at any 464 point in the key lifecycle. DNSViz is the best tools to show 465 problems in the chain. If you debug yourself use dig +multiline 466 so that you can see the key id of a DNSKEY. Common Variations of 467 this can be: 469 * DS pointing to a non existent key in the child zone. Questions 470 for consideration here include: Has there ever been a key (and, 471 if so, was it used)? Has there been a recent change in the 472 DNSKEY RRSet (indicating a key rollover)? Has the actual data 473 in the zone changed? Is the zone DNSSEC signed at all and has 474 it been in the past? 476 * DS pointing to an existent key, but no signatures are made with 477 the key. The checks above should be done, with the addition of 478 checking if another key in the DNSKEY RRSet is now used to sign 479 the records. 481 * Data in DS or DNSKEY doesn't match the other. This is more 482 common in initial setup when there was a copy and paste error. 483 Again checking history on data is the best you can do there. 485 All of the above is just a starting point for consideration when 486 deciding whether or not to deploy a trust anchor. It is not possible 487 to provide a simple checklist to run through to determine whether a 488 domain is broken because of an attack or an operator error. 490 8. Privacy Considerations 492 There are no privacy considerations in this document. 494 9. IANA Considerations 496 There are no IANA considerations in this document. 498 10. Security Considerations 500 End to end DNSSEC validation will be disabled during the time that an 501 NTA is used. In addition, the NTA may be in place after the point in 502 time when the DNS misconfiguration that caused validation to break 503 has been fixed. Thus, there may be a gap between when a domain has 504 been re-secured and when an NTA is removed. In addition, an NTA may 505 be put in place by DNS recursive resolver operators without the 506 knowledge of the authoritative domain administrator for a given 507 domain name. However, attempts SHOULD be made to contact and inform 508 the domain administrator prior to putting the NTA in place. 510 One side effect of implementing an NTA is that it may break client 511 applications that assume that a domain is signed and expect an AD bit 512 in the response. It is expected that many application that require 513 DNSSEC for a domain will perform their own validation, and so this 514 should not be a major issue. 516 11. Acknowledgements 518 Several people made contributions of text to this document and/or 519 played an important role in the development and evolution of this 520 document. This in some cases included performing a detailed review 521 of this document and then providing feedback and constructive 522 criticism for future revisions, or engaging in a healthy debate over 523 the subject of the document. All of this was helpful and therefore 524 the following individuals merit acknowledgement: Joe Abley, John 525 Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, 526 Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, 527 Christer Holmberg, Wes Hardaker, Paul Hoffman, Shane Kerr, Murray 528 Kucherawy, Rick Lamb, Marc Lampo, Scott Rose, Ted Lemon, A. Schulze, 529 Antoin Verschuren, Paul Vixie, Patrik Wallstrom, Nick Weaver, W.C.A. 530 Wijngaards, Suzanne Woolf. 532 Edward Lewis, Evan Hunt, Andrew Sullivan and Tatuya Jinmei provided 533 especially large amounts of text and / or detailed review. 535 12. References 537 12.1. Normative References 539 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 540 Rose, "DNS Security Introduction and Requirements", RFC 541 4033, March 2005. 543 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 544 Format", RFC 5914, June 2010. 546 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 547 Operational Practices, Version 2", RFC 6781, December 548 2012. 550 12.2. Informative References 552 [Alexa] Alexa, an Amazon.com Company, "Alexa "The top 500 sites on 553 the web. "", , May 2015, . 555 [Disclosure-Example] 556 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 557 Comcast , February 2013, 558 . 561 [Measuring-DNSSEC-Validation-of-Website-Visitors] 562 Mens, J., "Is my Web site being used via a DNSSEC- 563 validator?", July 2012, . 566 [Netalyzr] 567 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 568 "Implications of Netalyzr's DNS Measurements", Securing 569 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 570 2011, . 573 [Unbound-Configuration] 574 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 575 2010, . 578 Appendix A. Configuration Examples 580 The section contains example configurations to achieve Negative Trust 581 Anchor functionality for the zone foo.example.com. 583 Note: These are simply examples - nameserver operators are expected 584 to test and understand the implications of these operations. Note 585 also that some of available implementations may not implement all 586 recommended functionality in this document. In that case it is 587 advisable to request the developer or vendor of the implementation to 588 support the missing feature, rather than start using the incomplete 589 implementation. 591 A.1. NLNet Labs Unbound 593 Unbound lets us simply disable validation checking for a specific 594 zone by adding configuration statements to unbound.conf: 596 server: 597 domain-insecure: "foo.example.com" 599 Using the 'unbound-control' command one can add and remove Negative 600 Trust Anchors without restarting the nameserver. 602 Using the "unbound-control" command: 603 list_insecure list domain-insecure zones 604 insecure_add zone add domain-insecure zone 605 insecure_remove zone remove domain-insecure zone 607 Items added with the "unbound-control" command are added to the 608 running server and are lost when the server is restarted. Items from 609 unbound.conf stay after restart. 611 For additional information see [Unbound-Configuration] 613 A.2. ISC BIND 615 Use the "rndc" command: 617 nta -dump 618 List all negative trust anchors. 619 nta [-lifetime duration] [-force] domain [view] 620 Set a negative trust anchor, disabling DNSSEC validation 621 for the given domain. 622 Using -lifetime specifies the duration of the NTA, up 623 to one week. The default is one hour. 624 Using -force prevents the NTA from expiring before its 625 full lifetime, even if the domain can validate sooner. 626 nta -remove domain [view] 627 Remove a negative trust anchor, re-enabling validation 628 for the given domain. 630 A.3. Nominum Vantio 632 ** 634 *negative-trust-anchors* 636 _Format_: name 638 _Command Channel_: view.update name=world negative-trust- 639 anchors=(foo.example.com) 641 _Command Channel_: resolver.update name=res1 negative-trust- 642 anchors=(foo.example.com) 644 *Description*: Disables DNSSEC validation for a domain, even if the 645 domain is under an existing security root. 647 Appendix B. Document Change Log 649 [RFC Editor: This section is to be removed before publication] 651 -10.5 to 11 653 Integrated Alissa Cooper's No Objection comments. Text from Suz 654 and Evan. 656 -10.4 to 10.5 658 Integrated some comments from Ben Campbell's No Objection IESG 659 review. 661 -10.3 to 10.4 662 s/personnel trained in the operation of DNS servers MUST confirm/ 663 personnel trained in the operation of DNS servers must confirm/ - 664 Alissa Cooper, 666 -10.2 to 10.3 668 o Integrated comments from Gen-ART review - Christer Holmberg. 670 o Offlist comment from Tony Finch. Made the "Negative Trust Anchors 671 are intended to be temporary," sentence much better. 673 -10.1 to 10.2 675 o Incoroprated comments from IETF LC, including: 677 o A. Schulze - s/Unound/Unbound/ 679 o Joe Abley: Tone in into jarring. S1.2 s/domain administrator/zone 680 administrator/, dnscheck -> zonemaster 682 -10 to 10.1 684 o Fixed some typos (e.g Anrew -> Andrew) 686 -09 to -10 688 o 'Implementations MAY issue a warning or informational message when 689 this occurs' - changed SHOULD to MAY, per Evan. 691 -08 to -09 693 o Clarified that an NTA MUST take precedence over a positive, local 694 TA. 696 -07 to -08 698 o Added some cleanup from Paul Hoffman and Evan Hunt. 700 o Some better text on how to make Unbound do this, provided by 701 W.C.A. Wijngaards. 703 -06 to -07 705 o Addressed a large number of comments from Paul Hoffman, Scott Rose 706 and some more from Jinmei. 708 -05 to -06 709 o A bunch of comments from Tony Finch. 711 -04 to -05 713 o A large bunch of cleanups from Jinmei. Thanks! 715 o Also clarified that if there is an NTA at foo.bar.baz.example, and 716 a positive *trust anchor* at bar.baz.example, the most specific 717 wins. I'm not very happy with this text, any additional text 718 gratefully accepted... 720 -03 to -04: 722 o Addressed some comment from an email from Jinmei that I had 723 missed. Turns out others had made many of the same comments, and 724 so most had already been addressed. 726 -02 to -03: 728 o Included text from Ralph into Appendix B 730 o A bunch of comments from Andrew Sullivan ('[DNSOP] negative-trust- 731 anchors-02" - Mar 18th) 733 o Updated keywords 735 -01 to -02: 737 o Gah! I forgot to run spell check. And I type like a chimpanzee 738 with bad hand-eye coordination... 740 -00 to -01: 742 o Stole chunks of text from Ed Lewis' mailing list "tirade" :-) 744 o New rndc usage text from Evan. 746 o Deleted the (already resolved) open issues from Appendix C, moved 747 the unresolved issues into github, resolved them! 749 o Clarification that automated removal is best removal method, and 750 how to implement (Evan Hunt) 752 o Clarify that an NTA is not a RR (Rick Lamb) 754 o Grammar fixes. 756 Ind-07 - WG-00: 758 o Simply updated name to reflect WG doc. 760 Individual-00: First version published as an individual draft. 762 Individual-01: Fixed minor typos and grammatical nits. Closed all 763 open editorial items. 765 Individual-02: Simple date change to keep doc from expiring. 766 Substantive updates planned. 768 Individual-03: Changes to address feedback from Paul Vixie, by adding 769 a new section "Limited Time and Scope of Use". Changes to address 770 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 771 new section "Intentionally Broken Domains" and added two related 772 references. Added text to address the need for manual investigation, 773 as suggested by Patrik Falstrom. Added a suggestion on notification 774 as suggested by Marc Lampo. Made several additions and changes 775 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 776 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 778 Individual-04: Moved the section defining an NTA forward, and added 779 new text to the Abstract and Introduction per feedback from Paul 780 Hoffman. 782 Individual-05: Incorporated feedback from the DNSOP WG list received 783 on 2/17/13 and 2/18/13. This is likely the final version before the 784 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 785 per March Davids. 787 Individual-06: Added more OPEN issues to continue tracking WG 788 discussion. No changes in the main document - just expanded issue 789 tracking. 791 Individual-07: Refresh document - needs revision and rework before 792 IETF-91. Planning to add more contributors. 794 o Using github issue tracker - go see https://github.com/wkumari/ 795 draft-livingood-dnsop-negative-trust-anchors for more details. 797 o A bunch of readability improvments. 799 o Issue: Notify the domain owner of the validation failure - 800 resolved. 802 o Issue: Make the NTA as specific as possible - resolved. 804 Authors' Addresses 806 Paul Ebersman 807 Comcast 808 One Comcast Center 809 1701 John F. Kennedy Boulevard 810 Philadelphia, PA 19103 811 US 813 Email: ebersman-ietf@dragon.net 815 Chris Griffiths 817 Email: cgriffiths@gmail.com 819 Warren Kumari 820 Google 821 1600 Amphitheatre Parkway 822 Mountain View, CA 94043 823 US 825 Email: warren@kumari.net 826 URI: http://www.google.com 828 Jason Livingood 829 Comcast 830 One Comcast Center 831 1701 John F. Kennedy Boulevard 832 Philadelphia, PA 19103 833 US 835 Email: jason_livingood@cable.comcast.com 836 URI: http://www.comcast.com 838 Ralf Weber 839 Nominum 841 Email: Ralf.Weber@nominum.com 842 URI: http://www.nominum.com