idnits 2.17.00 (12 Aug 2021) /tmp/idnits62062/draft-ietf-dnsop-negative-trust-anchors-03.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 216: '...d in the operation of DNS servers MUST...' RFC 2119 keyword, line 242: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 243: '... Implementors SHOULD allow the opera...' RFC 2119 keyword, line 248: '...ive Trust Anchor MUST NOT be automatic...' RFC 2119 keyword, line 250: '...ive Trust Anchor SHOULD be used only i...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2015) is 2586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 513, 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: October 24, 2015 Dyn 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 April 22, 2015 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-ietf-dnsop-negative-trust-anchors-03 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 October 24, 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 . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . 6 73 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 74 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 7 75 6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 76 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Security Considerations . . . . . . . . . . . . . . . . . 8 78 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 9 79 7.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 9.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 85 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 11 86 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 11 87 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 12 88 Appendix B. Discovering broken domains . . . . . . . . . . . . . 12 89 Appendix C. Document Change Log . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction and motivation 94 This document defines a Negative Trust Anchor, which can be used 95 during the transition to ubiquitous DNSSEC deployment. Negative 96 Trust Anchors (NTAs) are configured locally on a validating DNS 97 recursive resolver to shield end users from DNSSEC-related 98 authoritative name server operational errors. Negative Trust Anchors 99 are intended to be temporary, and should not be distributed by IANA 100 or any other organization outside of the administrative boundary of 101 the organization locally implementing a Negative Trust Anchor. 102 Finally, Negative Trust Anchors pertain only to DNSSEC and not to 103 Public Key Infrastructures (PKI) such as X.509. 105 DNSSEC has now entered widespread deployment. However, the DNSSEC 106 signing tools and processes are less mature and reliable than those 107 for non-DNSSEC-related administration. As a result, operators of DNS 108 recursive resolvers, such as Internet Service Providers (ISPs), 109 occasionally observe domains incorrectly managing DNSSEC-related 110 resource records. This mismanagement triggers DNSSEC validation 111 failures, and then causes large numbers of end users to be unable to 112 reach a domain. Many end users tend to interpret this as a failure 113 of their ISP or resolver operator, and may switch to a non-validating 114 resolver or contact their ISP to complain, rather than seeing this as 115 a failure on the part of the domain they wanted to reach. Without 116 the techniques in this document, this pressure may cause the resolver 117 operator to disable (or simply not deploy) DNSSEC validation. Use of 118 a Negative Trust Anchor to temporarily disable DNSSEC validation for 119 a specific misconfigured domain name immediately restores access for 120 end users. This allows the domain's administrators to fix their 121 misconfiguration, while also allowing the organization using the 122 Negative Trust Anchor to keep DNSSEC validation enabled and still 123 reach the misconfigured domain. 125 It is worth noting the following text from RFC4033 [RFC4033] - "In 126 the final analysis, however, authenticating both DNS keys and data is 127 a matter of local policy, which may extend or even override the 128 protocol extensions defined in this document set." A responsibility 129 (one of many) of a caching server operator is to "protect the 130 integrity of the cache." 132 1.1. Definition of a Negative Trust Anchor 134 Trust Anchors are defined in [RFC5914]. A trust anchor should be 135 used by a validating caching resolver as a starting point for 136 building the authentication chain for a signed DNS response. By way 137 of analogy, negative trust anchors stop validation of the 138 authentication chain. Instead, the resolver sends the response as if 139 the zone is unsigned and does not set the AD bit. Note that this is 140 a behavior, and not a separate resource record. This Negative Trust 141 Anchor can potentially be implemented at any level within the chain 142 of trust and would stop validation from that point in the chain down. 144 1.2. Domain Validation Failures 146 A domain name can fail validation for two general reasons: a 147 legitimate security failure such as due to an attack or compromise of 148 some sort, or as a result of misconfiguration on the part of an 149 domain administrator. As domains transition to DNSSEC, the most 150 likely reason for a validation failure will be misconfiguration. 151 Thus, domain administrators should be sure to read [RFC6781] in full. 152 They should also pay special attention to Section 4.2, pertaining to 153 key rollovers, which appear to be the cause of many recent validation 154 failures. 156 It is also possible that some DNSSEC validation failures could arise 157 due to differences in how different software developers interpret 158 DNSSEC standards and/or how those developers choose to implement 159 support for DNSSEC. For example, it is conceivable that a domain may 160 be DNSSEC signed properly, and one vendor's DNS recursive resolvers 161 will validate the domain but other vendors' software may fail to 162 validate the domain. 164 1.3. End User Reaction 166 End users generally do not know of, understand, or care about the 167 resolution process that causes connections to happen. This is by 168 design: the point of the DNS is to insulate users from having to 169 remember IP addresses through a friendlier way of naming systems. It 170 follows from this that end users do not, and should not, be expected 171 to know about DNSSEC, validation, or anything of the sort. As a 172 result, end users may misinterpret the failure to reach a domain due 173 to DNSSEC-related misconfiguration . They may (incorrectly) assume 174 that their ISP is purposely blocking access to the domain or that it 175 is a performance failure on the part of their ISP (especially of the 176 ISP's DNS servers). They may contact their ISP to complain, which 177 will incur cost for their ISP. In addition, they may use online 178 tools and sites to complain of this problem, such as via a blog, web 179 forum, or social media site, which may lead to dissatisfaction on the 180 part of other end users or general criticism of an ISP or operator of 181 a DNS recursive resolver. 183 As end users publicize these failures, others may recommend they 184 switch from security-aware DNS resolvers to resolvers not performing 185 DNSSEC validation. This is a shame since the ISP or other DNS 186 recursive resolver operator is actually doing exactly what they are 187 supposed to do in failing to resolve a domain name, as this is the 188 expected result when a domain can no longer be validated, protecting 189 end users from a potential security threat. Use of a Negative Trust 190 Anchor would allow the ISP to specifically remedy the failure to 191 reach that domain, without compromising security for other sites. 193 This would result in a satisfied end user, with minimal impact to the 194 ISP, while maintaining the security of DNSSEC for correctly 195 maintained domains. 197 1.4. Switching to a Non-Validating Resolver is Not Recommended 199 As noted in Section 1.3, some people may consider switching to an 200 alternative, non-validating resolver themselves, or may recommend 201 that others do so. But if a domain fails DNSSEC validation and is 202 inaccessible, this could very well be due to a security-related 203 issue. In order to be as safe and secure as possible, end users 204 should not change to DNS servers that do not perform DNSSEC 205 validation as a workaround, and people should not recommend that 206 others do so either. Domains that fail DNSSEC for legitimate reasons 207 (versus misconfiguration) may be in control of hackers or there could 208 be other significant security issues with the domain. 210 Thus, switching to a non-validating resolver to restore access to a 211 domain that fails DNSSEC validation is not a recommended practice, is 212 bad advice to others, is potentially harmful to end user security. 214 2. Use of a Negative Trust Anchor 216 Technical personnel trained in the operation of DNS servers MUST 217 confirm that a failure is due to misconfiguration, as a similar 218 breakage could have occurred if an attacker gained access to a 219 domain's authoritative servers and modified those records or had the 220 domain pointed to their own rogue authoritative servers. They should 221 also confirm that the domain is not intentionally broken, such as for 222 testing purposes as noted in Section 6. Finally, they should make a 223 reasonable attempt to contact the domain owner of the misconfigured 224 zone, preferably prior to implementing the Negative Trust Anchor. 226 In the case of a validation failure due to misconfiguration of a TLD 227 or popular domain name (such as a top 100 website), this could make 228 content or services in the affected TLD or domain inaccessible for a 229 large number of users. In such cases, it may be appropriate to use a 230 Negative Trust Anchor as soon as the misconfiguration is confirmed. 232 Once a domain has been confirmed to fail DNSSEC validation due to a 233 DNSSEC-related misconfiguration, an ISP or other DNS recursive 234 resolver operator may elect to use a Negative Trust Anchor for that 235 domain or sub-domain. This instructs their DNS recursive resolver to 236 temporarily NOT perform DNSSEC validation at or in the misconfigured 237 domain. This immediately restores access to the domain for end users 238 while the domain's administrator corrects the misconfiguration(s). 239 It does not and should not involve turning off validation more 240 broadly. 242 A Negative Trust Anchor MUST only be used for a limited duration. 243 Implementors SHOULD allow the operator using the Negative Trust 244 Anchor to set an end time and date associated with any Negative Trust 245 Anchor. Optimally this time and date is set in a DNS recursive 246 resolver's configuration, though in the short-term this may also be 247 achieved via other systems or supporting processes. Use of a 248 Negative Trust Anchor MUST NOT be automatic. 250 Finally, a Negative Trust Anchor SHOULD be used only in a specific 251 domain or sub-domain and MUST NOT affect validation of other names up 252 the authentication chain. For example, a Negative Trust Anchor for 253 zone1.example.com would affect only names at or below 254 zone1.example.com, and validation would still be performed on 255 example.com, .com, and the root ("."). This Negative Trust Anchor 256 also SHOULD NOT affect names in another branch of the tree (such as 257 example.net). In another example, a Negative Trust Anchor for 258 example.com would affect only names within example.com, and 259 validation would still be performed on .com, and the root ("."). 261 Root (.) <====== 262 | || 263 | ||<======>+----+----+ DNSSEC 264 | || |Recursive| Validation 265 TLD (com) <=====|| |Resolver |<============> 266 | +<------>+---------+ 267 | | DNS NTA 268 | | (example.com) 269 SUB TLD (example.com) <------| <--------------> 270 | | 271 | | 272 | | 273 (zone1.example.com <-----| 275 Figure 1: Negative Trust Anchor Diagram 277 3. Managing Negative Trust Anchors 279 While Negative Trust Anchors have proven useful during the early 280 stages of DNSSEC adoption, domain owners are ultimately responsible 281 for managing and ensuring their DNS records are configured correctly. 283 Most current implementations of DNS validating resolvers currently 284 follow [RFC4033] on defining the implementation of Trust Anchor as 285 either using Delegation Signer (DS), Key Signing Key (KSK), or Zone 286 Signing Key (ZSK). A Negative Trust Anchor should use domain name 287 formatting that signifies where in a delegation a validation process 288 should be stopped. 290 Different DNS recursive resolvers may have different configuration 291 names for a Negative Trust Anchor. For example, Unbound calls their 292 configuration "domain-insecure." 294 [Unbound-Configuration] 296 4. Removal of a Negative Trust Anchor 298 As explored in Section 7.1, using an NTA once the zone correctly 299 validates can have security considerations. It is therefore 300 recommended that NTA implementors should periodically attempt to 301 validate the domain in question, for the period of time that the 302 Negative Trust Anchor is in place, until such validation is again 303 successful. NTAs MUST expire automatically when their configured 304 lifetime ends. The lifetime MUST NOT exceed a week. Before removing 305 the Negative Trust Anchor, all authoritative resolvers listed in the 306 zone should be checked (due to anycast and load balancers it may not 307 be possible to check all instances). 309 Once all testing succeeds, a Negative Trust Anchor should be removed 310 as soon as is reasonably possible. One possible method to 311 automatically determine when the NTA can be removed is to send a 312 periodic query for type SOA at the NTA node; if it gets a response 313 that it can validate (whether the response was an actual SOA answer 314 or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is 315 presumed no longer to be necessary and is removed. Implementations 316 SHOULD, by default, perform this operation. Note that under some 317 circumstances this is undesirable behavior (for example, if 318 www.example.com has a bad signature, but example.com/SOA is fine) and 319 so implementations may wish to allow the operator to override this 320 spot-check / behavior. 322 When removing the NTA, the implementation should remove all cached 323 entries below the NTA node. 325 5. Comparison to Other DNS Misconfigurations 327 Domain administrators are ultimately responsible for managing and 328 ensuring their DNS records are configured correctly. ISPs or other 329 DNS recursive resolver operators cannot and should not correct 330 misconfigured A, CNAME, MX, or other resource records of domains for 331 which they are not authoritative. Expecting non-authoritative 332 entities to protect domain administrators from any misconfiguration 333 of resource records is therefore unrealistic and unreasonable, and in 334 the long-term is harmful to the delegated design of the DNS and could 335 lead to extensive operational instability and/or variation. 337 6. Intentionally Broken Domains 339 Some domains, such as dnssec-failed.org, have been intentionally 340 broken for testing purposes 341 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 342 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 343 If an end user is querying a validating DNS recursive resolver, then 344 this or other similarly intentionally broken domains should fail to 345 resolve and should result in a SERVFAIL error. If such a domain 346 resolved successfully, then it is a sign that the DNS recursive 347 resolver is not fully validating. 349 Organizations that utilize Negative Trust Anchors should not add a 350 Negative Trust Anchor for any intentionally broken domain. 352 Organizations operating an intentionally broken domain may wish to 353 consider adding a TXT record for the domain to the effect of "This 354 domain is purposely DNSSEC broken for testing purposes". 356 7. Other Considerations 358 7.1. Security Considerations 360 End to end DNSSEC validation will be disabled during the time that a 361 Negative Trust Anchor is used. In addition, the Negative Trust 362 Anchor may be in place after the point in time when the DNS 363 misconfiguration that caused validation to break has been fixed. 364 Thus, there may be a gap between when a domain has have been re- 365 secured and when a Negative Trust Anchor is removed. In addition, a 366 Negative Trust Anchor may be put in place by DNS recursive resolver 367 operators without the knowledge of the authoritative domain 368 administrator for a given domain name. However, attempts SHOULD be 369 made to contact and inform the domain administrator prior to putting 370 the NTA in place. 372 End users of a DNS recursive resolver or other people may wonder why 373 a domain that fails DNSSEC validation resolves with a supposedly 374 validating resolver. As a result, implementors should consider 375 transparently disclosing those Negative Trust Anchors which are 376 currently in place or were in place in the past, such as on a website 377 [Disclosure-Example]. This is particularly important since there is 378 currently no special DNS query response code that could indicate to 379 end users or applications that a Negative Trust Anchor is in place. 380 Such disclosures should optimally include both the data and time that 381 the Negative Trust Anchor was put in place and when it was removed. 383 7.2. Privacy Considerations 385 There are no privacy considerations in this document. 387 7.3. IANA Considerations 389 There are no IANA considerations in this document. 391 8. Acknowledgements 393 Several people made contributions of text to this document and/or 394 played an important role in the development and evolution of this 395 document. This in some cases included performing a detailed review 396 of this document and then providing feedback and constructive 397 criticism for future revisions, or engaging in a healthy debate over 398 the subject of the document. All of this was helpful and therefore 399 the following individuals merit acknowledgement: 401 - Joe Abley 403 - John Barnitz 405 - Tom Creighton 407 - Marco Davids 409 - Brian Dickson 411 - Patrik Falstrom 413 - Tony Finch 415 - Chris Ganster 417 - Olafur Gudmundsson 419 - Peter Hagopian 421 - Wes Hardaker 423 - Paul Hoffman 425 - Shane Kerr 427 - Murray Kucherawy 429 - Warren Kumari 430 - Rick Lamb 432 - Marc Lampo 434 - Ted Lemon 436 - Ed Lewis 438 - Antoin Verschuren 440 - Paul Vixie 442 - Patrik Wallstrom 444 - Nick Weaver 446 - Ralf Weber 448 Edward Lewis, Evan Hunt and Andew Sullivan provided especially large 449 amounts of text and / or detailed review. 451 9. References 453 9.1. Normative References 455 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 456 Rose, "DNS Security Introduction and Requirements", RFC 457 4033, March 2005. 459 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 460 Format", RFC 5914, June 2010. 462 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 463 Operational Practices, Version 2", RFC 6781, December 464 2012. 466 9.2. Informative References 468 [Disclosure-Example] 469 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 470 Comcast , February 2013, . 473 [Measuring-DNSSEC-Validation-of-Website-Visitors] 474 Mens, J., "Is my Web site being used via a DNSSEC- 475 validator?", July 2012, . 478 [Netalyzr] 479 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 480 "Implications of Netalyzr's DNS Measurements", Securing 481 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 482 2011, . 485 [Unbound-Configuration] 486 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 487 2010, . 490 Appendix A. Configuration Examples 492 The section contains example configurations to achieve Negative Trust 493 Anchor functionality for the zone foo.example.com. 495 Please note: These are simply examples - nameserver operators are 496 expected to test and understand the implications of these operations. 498 A.1. NLNet Labs Unbound 500 Unbound lets us simply disable validation checking for a specific 501 zone. See: [ TODO(WK): Make this a "real" reference ] 504 server: 505 domain-insecure: "foo.example.com" 507 A.2. ISC BIND 509 Use the "rndc" command: 511 nta -dump 512 List all negative trust anchors. 513 nta [-lifetime duration] [-force] domain [view] 514 Set a negative trust anchor, disabling DNSSEC validation 515 for the given domain. 516 Using -lifetime specifies the duration of the NTA, up 517 to one week. The default is one hour. 518 Using -force prevents the NTA from expiring before its 519 full lifetime, even if the domain can validate sooner. 520 nta -remove domain [view] 521 Remove a negative trust anchor, re-enabling validation 522 for the given domain. 524 A.3. Nominum Vantio 526 ** 528 *negative-trust-anchors* 530 _Format_: name 532 _Command Channel_: view.update name=world negative-trust- 533 anchors=(foo.example.com) 535 _Command Channel_: resolver.update name=res1 negative-trust- 536 anchors=(foo.example.com) 538 *Description*: Disables DNSSEC validation for a domain, even if the 539 domain is under an existing security root. 541 Appendix B. Discovering broken domains 543 Discovering that a domain is DNSSEC broken as result of an operator 544 error instead of an attack is not trivial and the examples here 545 should be vetted by an experienced professional before taking the 546 decision on implementing an negative trust anchor. 548 One of the key thing to look for when looking at a DNSSEC broken 549 domain is consistency and history. It therefore is good if you have 550 the ability to look at the servers DNS traffic over a long period of 551 time or have a database that stores DNS names associated answers 552 (this is often referred to as a "passive DNS database"). Another 553 invaluable tool is dnsviz (http://www.dnsivz.net) which also stores 554 DNSSEC related data historically. The drawback here is that you need 555 to have it test the domain before the incident occurs which might not 556 always be the case. 558 The first and easiest thing to check is if the failure of the domain 559 is consistent across different software implementations. If not you 560 want to inform the vendor where it fails to look deeper in the issue. 562 The next thing is to figure out what the actual failure mode is. 563 There are several tools do this, an incomplete list includes: 565 o DNSViz (http://dnsviz.net) 567 o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) 569 o iis.se DNS check (http://dnscheck.iis.se) 570 most of these tools are open source so you can them install locally 571 if you want. 573 Using the tools over the Internet has the advantage though that as 574 these are not located in the same part of the network you already 575 will have more than local view by using different tools. 577 Once you figure out what the error is you need to check if it shows 578 consistently around the world and from all authoritative server.s Use 579 DNS Tools (dig) or DNS looking glasses to verify this. An error that 580 is consistently the same is more likely to be operator caused than an 581 attack, although that is not an guarantee. Also if the output from 582 the authoritative server is consistently different from the resolvers 583 output this hints to an attack rather then an error, unless there is 584 EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to 585 the domain. 587 A last check is to look at the actual DNS data. Is the result of the 588 query still the same or has it changed? While a lot of DNSSEC errors 589 occur on events that changes DNSSEC data the actual record someone 590 wants to go often stays the same. Again if the data is the same this 591 is an indication that the error is operator caused not an guarantee. 592 Keep in mind that with DNS being used to globally balance traffic the 593 data associated to a name might be different in different parts of 594 the Internet. 596 Here are some examples of common DNSSEC failures that have been seen 597 as operator signing errors on the Internet: 599 o RRSIG timing issue. Each signature has an inception and expiry 600 time in which between it is valid. Letting this time expire 601 without creating a new signature is one of the most common DNSSEC 602 errors. To a lesser extent it also happened that signatures where 603 made active before the inception time. For all of these errors 604 your primary check is to check on the data. Signature expiration 605 is also about the only error we see on actual data (like 606 www.example.com). All other errors are more or less related to 607 dealing with the chain of trust established by DS records in the 608 parent zone and DNSKEYs in the child zones. These mostly occur 609 during key rollovers, but are not limited to that. 611 o DNSKEYs in child zone don't match parents zone DS record. There 612 is a big variation of this that can happen at any point in the key 613 lifecycle. DNSViz is the best tools to show problems in the 614 chain. If you debug yourself use dig +multiline so that you can 615 see the key id of a DNSKEY. Common Variations of this can be: 617 o DS pointing to a non existent key in the child zone. Questions 618 for considerations here are: Has the existed before and was used? 619 Was there a change in the DNSKEY RRSet recently (indicating a key 620 rollover) and of course has the actual data in the zone changes. 621 Is the zone DNSSEC signed at all and has it been in the past? 623 o DS pointing to an existent key, but no signatures are made with 624 the key. Again the checks above should be done with addition of 625 checking if another key in the DNSKEY RRSet is now used to sign 626 the records. 628 o Data in DS or DNSKEY doesn't match the other. This is more common 629 in initial setup when there was a copy and paste error. Again 630 checking history on data is the best you can do there. It's not 631 possible to give a checklist just to run through to decide if a 632 domain is broken because of an attack or an operator error. 634 All of the above is just a starting point for consideration when 635 having to decide to deploy or not deploy a trust anchor. 637 Appendix C. Document Change Log 639 [RFC Editor: This section is to be removed before publication] 641 -02 to -03: 643 o Included text from Ralph into Appendix B 645 o A bunch of comments from Andrew Sullivan ('[DNSOP] negative-trust- 646 anchors-02" - Mar 18th) 648 o Updated keywords 650 -01 to -02: 652 o Gah! I forgot to run spell check. And I type like a chimpanzee 653 with bad hand-eye coordination... 655 -00 to -01: 657 o Stole chunks of text from Ed Lewis' mailing list "tirade" :-) 659 o New rndc usage text from Evan. 661 o Deleted the (already resolved) open issues from Appendix C, moved 662 the unresolved issues into github, resolved them! 664 o Clarification that automated removal is best removal method, and 665 how to implement (Evan Hunt) 667 o Clarify that an NTA is not a RR (Rick Lamb) 669 o Grammar fixes. 671 Ind-07 - WG-00: 673 o Simply updated name to reflect WG doc. 675 Individual-00: First version published as an individual draft. 677 Individual-01: Fixed minor typos and grammatical nits. Closed all 678 open editorial items. 680 Individual-02: Simple date change to keep doc from expiring. 681 Substantive updates planned. 683 Individual-03: Changes to address feedback from Paul Vixie, by adding 684 a new section "Limited Time and Scope of Use". Changes to address 685 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 686 new section "Intentionally Broken Domains" and added two related 687 references. Added text to address the need for manual investigation, 688 as suggested by Patrik Falstrom. Added a suggestion on notification 689 as suggested by Marc Lampo. Made several additions and changes 690 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 691 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 693 Individual-04: Moved the section defining a NTA forward, and added 694 new text to the Abstract and Introduction per feedback from Paul 695 Hoffman. 697 Individual-05: Incorporated feedback from the DNSOP WG list received 698 on 2/17/13 and 2/18/13. This is likely the final version before the 699 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 700 per March Davids. 702 Individual-06: Added more OPEN issues to continue tracking WG 703 discussion. No changes in the main document - just expanded issue 704 tracking. 706 Individual-07: Refresh document - needs revision and rework before 707 IETF-91. Planning to add more contributors. 709 o Using github issue tracker - go see https://github.com/wkumari/ 710 draft-livingood-dnsop-negative-trust-anchors for more details. 712 o A bunch of readability improvments. 714 o Issue: Notify the domain owner of the validation failure - 715 resolved. 717 o Issue: Make the NTA as specific as possible - resolved. 719 Authors' Addresses 721 Paul Ebersman 722 Comcast 723 One Comcast Center 724 1701 John F. Kennedy Boulevard 725 Philadelphia, PA 19103 726 US 728 Email: ebersman-ietf@dragon.net 730 Chris Griffiths 731 Dyn 732 150 Dow Street 733 Tower Two 734 Manchester, NH 03101 735 US 737 Email: cgriffiths@gmail.com 738 URI: http://www.dyn.com 740 Warren Kumari 741 Google 742 1600 Amphitheatre Parkway 743 Mountain View, CA 94043 744 US 746 Email: warren@kumari.net 747 URI: http://www.google.com 748 Jason Livingood 749 Comcast 750 One Comcast Center 751 1701 John F. Kennedy Boulevard 752 Philadelphia, PA 19103 753 US 755 Email: jason_livingood@cable.comcast.com 756 URI: http://www.comcast.com 758 Ralf Weber 759 Nominum 761 Email: Ralf.Weber@nominum.com 762 URI: http://www.nominum.com