idnits 2.17.1 draft-ietf-dnsop-negative-trust-anchors-05.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 219: '...d in the operation of DNS servers MUST...' RFC 2119 keyword, line 248: '...ive Trust Anchor MUST only be used for...' RFC 2119 keyword, line 249: '... Implementors SHOULD allow the opera...' RFC 2119 keyword, line 254: '...ive Trust Anchor MUST NOT be automatic...' RFC 2119 keyword, line 256: '...ive Trust Anchor SHOULD be used only i...' (8 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 5, 2015) is 3250 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-force' is mentioned on line 482, but not defined == Unused Reference: 'Unbound-Configuration' is defined on line 450, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations P. Ebersman 3 Internet-Draft Comcast 4 Intended status: Informational C. Griffiths 5 Expires: November 6, 2015 6 W. Kumari 7 Google 8 J. Livingood 9 Comcast 10 R. Weber 11 Nominum 12 May 5, 2015 14 Definition and Use of DNSSEC Negative Trust Anchors 15 draft-ietf-dnsop-negative-trust-anchors-05 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 6, 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 . . . . . . . . . . . . . . . 7 73 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 74 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 9.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 10 85 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 10 86 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 11 87 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 11 88 Appendix B. Discovering broken domains . . . . . . . . . . . . . 11 89 Appendix C. Document Change Log . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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. 143 Validation starts again if there is a positive trust anchor further 144 down in the chain. For example, if there is a NTA at example.com, 145 and a positive trust anchor at foo.bar.example.com, then validation 146 resumes for foo.bar.example.com and anything below it. 148 1.2. 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 an 153 domain administrator. As domains transition to DNSSEC, the most 154 likely reason for a validation failure will be misconfiguration. 155 Thus, domain administrators should be sure to read [RFC6781] in full. 156 They should also pay special attention to Section 4.2, pertaining to 157 key 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.3. End User Reaction 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 a 194 Negative Trust Anchor would allow the ISP to specifically remedy the 195 failure to reach that domain, without compromising security for other 196 sites. This would result in a satisfied end user, with minimal 197 impact to the ISP, while maintaining the security of DNSSEC for 198 correctly maintained domains. 200 1.4. Switching to a Non-Validating Resolver is Not Recommended 202 As noted in Section 1.3, some people may consider switching to an 203 alternative, non-validating resolver themselves, or may recommend 204 that others do so. But if a domain fails DNSSEC validation and is 205 inaccessible, this could very well be due to a security-related 206 issue. In order to be as safe and secure as possible, end users 207 should not change to DNS servers that do not perform DNSSEC 208 validation as a workaround, and people should not recommend that 209 others do so either. Domains that fail DNSSEC for legitimate reasons 210 (versus misconfiguration) may be in control of hackers or there could 211 be other significant security issues with the domain. 213 Thus, switching to a non-validating resolver to restore access to a 214 domain that fails DNSSEC validation is not a recommended practice, is 215 bad advice to others, is potentially harmful to end user security. 217 2. Use of a Negative Trust Anchor 219 Technical personnel trained in the operation of DNS servers MUST 220 confirm that a failure is due to misconfiguration, as a similar 221 breakage could have occurred if an attacker gained access to a 222 domain's authoritative servers and modified those records or had the 223 domain pointed to their own rogue authoritative servers. They should 224 also confirm that the domain is not intentionally broken, such as for 225 testing purposes as noted in Section 6. Finally, they should make a 226 reasonable attempt to contact the domain owner of the misconfigured 227 zone, preferably prior to implementing the Negative Trust Anchor. 228 Involving trained technical personnel is costly, but operational 229 experience suggests that this is a very rare event such as around 230 once per quarter (or even less). 232 In the case of a validation failure due to misconfiguration of a TLD 233 or popular domain name (such as a top 100 website), content or 234 services in the affected TLD or domain could be inaccessible for a 235 large number of users. In such cases, it may be appropriate to use a 236 Negative Trust Anchor as soon as the misconfiguration is confirmed. 238 Once a domain has been confirmed to fail DNSSEC validation due to a 239 DNSSEC-related misconfiguration, an ISP or other DNS recursive 240 resolver operator may elect to use a Negative Trust Anchor for that 241 domain or sub-domain. This instructs their DNS recursive resolver to 242 temporarily NOT perform DNSSEC validation at or in the misconfigured 243 domain. This immediately restores access to the domain for end users 244 while the domain's administrator corrects the misconfiguration(s). 245 It does not and should not involve turning off validation more 246 broadly. 248 A Negative Trust Anchor MUST only be used for a limited duration. 249 Implementors SHOULD allow the operator using the Negative Trust 250 Anchor to set an end time and date associated with any Negative Trust 251 Anchor. Optimally, this time and date is set in a DNS recursive 252 resolver's configuration, though in the short-term this may also be 253 achieved via other systems or supporting processes. Use of a 254 Negative Trust Anchor MUST NOT be automatic. 256 Finally, a Negative Trust Anchor SHOULD be used only in a specific 257 domain or sub-domain and MUST NOT affect validation of other names up 258 the authentication chain. For example, a Negative Trust Anchor for 259 zone1.example.com would affect only names at or below 260 zone1.example.com, and validation would still be performed on 261 example.com, .com, and the root ("."). This Negative Trust Anchor 262 also SHOULD NOT affect names in another branch of the tree (such as 263 example.net). In another example, a Negative Trust Anchor for 264 example.com would affect only names within example.com, and 265 validation would still be performed on .com, and the root ("."). In 266 this scenario, if there is a (probably manually configured) trust 267 anchor for zone1.example.com, validation would be performed for 268 zone1.example.com and subdomains of zone1.example.com. 270 Root (.) <====== 271 | || 272 | ||<======>+----+----+ DNSSEC 273 | || |Recursive| Validation 274 TLD (com) <=====|| |Resolver |<============> 275 | +<------>+---------+ 276 | | DNS NTA 277 | | (example.com) 278 SUB TLD (example.com) <------| <--------------> 279 | | 280 | | 281 | | 282 (zone1.example.com <-----| 284 Figure 1: Negative Trust Anchor Diagram 286 3. Managing Negative Trust Anchors 288 While Negative Trust Anchors have proven useful during the early 289 stages of DNSSEC adoption, domain owners are ultimately responsible 290 for managing and ensuring their DNS records are configured correctly. 292 Most current implementations of DNS validating resolvers currently 293 follow [RFC4033] on defining the implementation of Trust Anchor as 294 either using Delegation Signer (DS), Key Signing Key (KSK), or Zone 295 Signing Key (ZSK). A Negative Trust Anchor should use domain name 296 formatting that signifies where in a delegation a validation process 297 should be stopped. 299 Different DNS recursive resolvers may have different configuration 300 names for a Negative Trust Anchor. For example, Unbound calls their 301 configuration "domain-insecure."[Unbound-Configuration] 303 4. Removal of a Negative Trust Anchor 305 As explored in Section 7.1, using an NTA once the zone correctly 306 validates can have security considerations. It is therefore 307 RECOMMENDED that NTA implementors SHOULD periodically attempt to 308 validate the domain in question, for the period of time that the 309 Negative Trust Anchor is in place, until such validation is again 310 successful. NTAs MUST expire automatically when their configured 311 lifetime ends. The lifetime MUST NOT exceed a week. Before removing 312 the Negative Trust Anchor, all authoritative resolvers listed in the 313 zone should be checked (due to anycast and load balancers it may not 314 be possible to check all instances). 316 Once all testing succeeds, a Negative Trust Anchor should be removed 317 as soon as is reasonably possible. One possible method to 318 automatically determine when the NTA can be removed is to send a 319 periodic query for type SOA at the NTA node; if it gets a response 320 that it can validate (whether the response was an actual SOA answer 321 or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is 322 presumed no longer to be necessary and is removed. Implementations 323 SHOULD, by default, perform this operation. Note that under some 324 circumstances this is undesirable behavior (for example, if 325 www.example.com has a bad signature, but example.com/SOA is fine) and 326 so implementations may wish to allow the operator to override this 327 spot-check / behavior. 329 When removing the NTA, the implementation SHOULD remove all cached 330 entries below the NTA node. 332 5. Comparison to Other DNS Misconfigurations 334 Domain administrators are ultimately responsible for managing and 335 ensuring their DNS records are configured correctly. ISPs or other 336 DNS recursive resolver operators cannot and should not correct 337 misconfigured A, CNAME, MX, or other resource records of domains for 338 which they are not authoritative. Expecting non-authoritative 339 entities to protect domain administrators from any misconfiguration 340 of resource records is therefore unrealistic and unreasonable, and in 341 the long-term is harmful to the delegated design of the DNS and could 342 lead to extensive operational instability and/or variation. 344 6. Intentionally Broken Domains 346 Some domains, such as dnssec-failed.org, have been intentionally 347 broken for testing purposes 348 [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For 349 example, dnssec-failed.org is a DNSSEC-signed domain that is broken. 350 If an end user is querying a validating DNS recursive resolver, then 351 this or other similarly intentionally broken domains should fail to 352 resolve and should result in a "Server Failure" error (RCODE 2, also 353 known as 'SERVFAIL'). If such a domain resolved successfully, then 354 it is a sign that the DNS recursive resolver is not fully validating. 356 Organizations that utilize Negative Trust Anchors should not add a 357 Negative Trust Anchor for any intentionally broken domain. 359 Organizations operating an intentionally broken domain may wish to 360 consider adding a TXT record for the domain to the effect of "This 361 domain is purposely DNSSEC broken for testing purposes". 363 7. Other Considerations 365 7.1. Security Considerations 367 End to end DNSSEC validation will be disabled during the time that a 368 Negative Trust Anchor is used. In addition, the Negative Trust 369 Anchor may be in place after the point in time when the DNS 370 misconfiguration that caused validation to break has been fixed. 371 Thus, there may be a gap between when a domain has been re-secured 372 and when a Negative Trust Anchor is removed. In addition, a Negative 373 Trust Anchor may be put in place by DNS recursive resolver operators 374 without the knowledge of the authoritative domain administrator for a 375 given domain name. However, attempts SHOULD be made to contact and 376 inform the domain administrator prior to putting the NTA in place. 378 End users of a DNS recursive resolver or other people may wonder why 379 a domain that fails DNSSEC validation resolves with a supposedly 380 validating resolver. As a result, implementors should consider 381 transparently disclosing those Negative Trust Anchors which are 382 currently in place or were in place in the past, such as on a website 383 [Disclosure-Example]. This is particularly important since there is 384 currently no special DNS query response code that could indicate to 385 end users or applications that a Negative Trust Anchor is in place. 386 Such disclosures should optimally include both the data and time that 387 the Negative Trust Anchor was put in place and when it was removed. 389 7.2. Privacy Considerations 391 There are no privacy considerations in this document. 393 7.3. IANA Considerations 395 There are no IANA considerations in this document. 397 8. Acknowledgements 399 Several people made contributions of text to this document and/or 400 played an important role in the development and evolution of this 401 document. This in some cases included performing a detailed review 402 of this document and then providing feedback and constructive 403 criticism for future revisions, or engaging in a healthy debate over 404 the subject of the document. All of this was helpful and therefore 405 the following individuals merit acknowledgement: Joe Abley,John 406 Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, 407 Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes 408 Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc 409 Lampo, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik Wallstrom, 410 Nick Weaver 412 Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided 413 especially large amounts of text and / or detailed review. 415 9. References 417 9.1. Normative References 419 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 420 Rose, "DNS Security Introduction and Requirements", RFC 421 4033, March 2005. 423 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 424 Format", RFC 5914, June 2010. 426 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 427 Operational Practices, Version 2", RFC 6781, December 428 2012. 430 9.2. Informative References 432 [Disclosure-Example] 433 Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", 434 Comcast , February 2013, 435 . 438 [Measuring-DNSSEC-Validation-of-Website-Visitors] 439 Mens, J., "Is my Web site being used via a DNSSEC- 440 validator?", July 2012, . 443 [Netalyzr] 444 Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, 445 "Implications of Netalyzr's DNS Measurements", Securing 446 and Trusting Internet Names, SATIN 2011 SATIN 2011, April 447 2011, . 450 [Unbound-Configuration] 451 Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 452 2010, . 455 Appendix A. Configuration Examples 457 The section contains example configurations to achieve Negative Trust 458 Anchor functionality for the zone foo.example.com. 460 Note: These are simply examples - nameserver operators are expected 461 to test and understand the implications of these operations. Note 462 also that some of available implementations may not implement all 463 recommended functionality in this document. In that case it is 464 advisable to request the developer or vendor of the implementation to 465 support the missing feature, rather than start using the incomplete 466 implementation. 468 A.1. NLNet Labs Unbound 470 Unbound lets us simply disable validation checking for a specific 471 zone. See: 473 server: 474 domain-insecure: "foo.example.com" 476 A.2. ISC BIND 478 Use the "rndc" command: 480 nta -dump 481 List all negative trust anchors. 482 nta [-lifetime duration] [-force] domain [view] 483 Set a negative trust anchor, disabling DNSSEC validation 484 for the given domain. 485 Using -lifetime specifies the duration of the NTA, up 486 to one week. The default is one hour. 487 Using -force prevents the NTA from expiring before its 488 full lifetime, even if the domain can validate sooner. 489 nta -remove domain [view] 490 Remove a negative trust anchor, re-enabling validation 491 for the given domain. 493 A.3. Nominum Vantio 495 ** 497 *negative-trust-anchors* 499 _Format_: name 501 _Command Channel_: view.update name=world negative-trust- 502 anchors=(foo.example.com) 504 _Command Channel_: resolver.update name=res1 negative-trust- 505 anchors=(foo.example.com) 507 *Description*: Disables DNSSEC validation for a domain, even if the 508 domain is under an existing security root. 510 Appendix B. Discovering broken domains 512 Discovering that a domain is DNSSEC broken as result of an operator 513 error instead of an attack is not trivial, and the examples here 514 should be vetted by an experienced professional before taking the 515 decision on implementing an negative trust anchor. 517 One of the key thing to look for when looking at a DNSSEC broken 518 domain is consistency and history. It therefore is good if you have 519 the ability to look at the server's DNS traffic over a long period of 520 time or have a database that stores DNS names associated answers 521 (this is often referred to as a "passive DNS database"). Another 522 invaluable tool is dnsviz (http://www.dnsivz.net) which also stores 523 DNSSEC related data historically. The drawback here is that you need 524 to have it test the domain before the incident occurs. 526 The first and easiest thing to check is if the failure of the domain 527 is consistent across different software implementations. If not, you 528 want to inform the vendor where it fails so that the vendor can look 529 more deeply into the issue. 531 The next thing is to figure out what the actual failure mode is. 532 There are several tools do this, an incomplete list includes: 534 o DNSViz (http://dnsviz.net) 536 o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) 538 o iis.se DNS check (http://dnscheck.iis.se) 540 most of these tools are open source and can be installed locally. 541 However, using the tools over the Internet has the advantage of 542 providing visibility from a different point. 544 Once you figure out what the error is, you need to check if it shows 545 consistently around the world and from all authoritative servers. 546 Use DNS Tools (dig) or DNS looking glasses to verify this. An error 547 that is consistently the same is more likely to be operator caused 548 than an attack. Also if the output from the authoritative server is 549 consistently different from the resolvers output this hints to an 550 attack rather then an error, unless there is EDNS0 client subnet 551 (draft-ietf-dnsop-edns-client-subnet) applied to the domain. 553 A last check is to look at the actual DNS data. Is the result of the 554 query still the same or has it changed? While a lot of DNSSEC errors 555 occur on events that change DNSSEC data, the actual record someone 556 wants to go to often stays the same. If the data is the same, this 557 is an indication (not a guarantee) that the error is operator caused. 558 Keep in mind that with DNS being used to globally balance traffic the 559 data associated to a name might be different in different parts of 560 the Internet. 562 Here are some examples of common DNSSEC failures that have been seen 563 as operator signing errors on the Internet: 565 o RRSIG timing issue. Each signature has an inception time and 566 expiry time, between which it is valid. Letting this time expire 567 without creating a new signature is one of the most common DNSSEC 568 errors. To a lesser extent, this also occurs if signatures were 569 made active before the inception time. For all of these errors 570 your primary check is to check on the data. Signature expiration 571 is also about the only error we see on actual data (like 572 www.example.com). All other errors are more or less related to 573 dealing with the chain of trust established by DS records in the 574 parent zone and DNSKEYs in the child zones. These mostly occur 575 during key rollovers, but are not limited to that. 577 o DNSKEYs in child zone don't match the DS record in the parent 578 zone. There is a big variation of this that can happen at any 579 point in the key lifecycle. DNSViz is the best tools to show 580 problems in the chain. If you debug yourself use dig +multiline 581 so that you can see the key id of a DNSKEY. Common Variations of 582 this can be: 584 o DS pointing to a non existent key in the child zone. Questions 585 for consideration here include: Has there ever been a key (and, if 586 so, was it used)? Has there been a recent change in the DNSKEY 587 RRSet (indicating a key rollover)? Has the actual data in the 588 zone changed? Is the zone DNSSEC signed at all and has it been in 589 the past? 591 o DS pointing to an existent key, but no signatures are made with 592 the key. The checks above should be done, with the addition of 593 checking if another key in the DNSKEY RRSet is now used to sign 594 the records. 596 o Data in DS or DNSKEY doesn't match the other. This is more common 597 in initial setup when there was a copy and paste error. Again 598 checking history on data is the best you can do there. 600 All of the above is just a starting point for consideration when 601 deciding whether or not to deploy a trust anchor. It is not possible 602 to provide a simple checklist to run through to determine if a domain 603 is broken because of an attack or an operator error. 605 Appendix C. Document Change Log 607 [RFC Editor: This section is to be removed before publication] 609 -04 to -05 611 o A large bunch of cleanups from Jinmei. Thanks! 613 o Also clarified that if there is an NTA at foo.bar.baz.example, and 614 a positive *trust anchor* at bar.baz.example, the most specific 615 wins. I'm not very happy with this text, any additional text 616 gratefully accepted... 618 -03 to -04: 620 o Addressed some comment from an email from Jinmei that I had 621 missed. Turns out others had made many of the same comments, and 622 so most had already been addressed. 624 -02 to -03: 626 o Included text from Ralph into Appendix B 628 o A bunch of comments from Andrew Sullivan ('[DNSOP] negative-trust- 629 anchors-02" - Mar 18th) 631 o Updated keywords 633 -01 to -02: 635 o Gah! I forgot to run spell check. And I type like a chimpanzee 636 with bad hand-eye coordination... 638 -00 to -01: 640 o Stole chunks of text from Ed Lewis' mailing list "tirade" :-) 642 o New rndc usage text from Evan. 644 o Deleted the (already resolved) open issues from Appendix C, moved 645 the unresolved issues into github, resolved them! 647 o Clarification that automated removal is best removal method, and 648 how to implement (Evan Hunt) 650 o Clarify that an NTA is not a RR (Rick Lamb) 652 o Grammar fixes. 654 Ind-07 - WG-00: 656 o Simply updated name to reflect WG doc. 658 Individual-00: First version published as an individual draft. 660 Individual-01: Fixed minor typos and grammatical nits. Closed all 661 open editorial items. 663 Individual-02: Simple date change to keep doc from expiring. 664 Substantive updates planned. 666 Individual-03: Changes to address feedback from Paul Vixie, by adding 667 a new section "Limited Time and Scope of Use". Changes to address 668 issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a 669 new section "Intentionally Broken Domains" and added two related 670 references. Added text to address the need for manual investigation, 671 as suggested by Patrik Falstrom. Added a suggestion on notification 672 as suggested by Marc Lampo. Made several additions and changes 673 suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane 674 Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. 676 Individual-04: Moved the section defining a NTA forward, and added 677 new text to the Abstract and Introduction per feedback from Paul 678 Hoffman. 680 Individual-05: Incorporated feedback from the DNSOP WG list received 681 on 2/17/13 and 2/18/13. This is likely the final version before the 682 IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, 683 per March Davids. 685 Individual-06: Added more OPEN issues to continue tracking WG 686 discussion. No changes in the main document - just expanded issue 687 tracking. 689 Individual-07: Refresh document - needs revision and rework before 690 IETF-91. Planning to add more contributors. 692 o Using github issue tracker - go see https://github.com/wkumari/ 693 draft-livingood-dnsop-negative-trust-anchors for more details. 695 o A bunch of readability improvments. 697 o Issue: Notify the domain owner of the validation failure - 698 resolved. 700 o Issue: Make the NTA as specific as possible - resolved. 702 Authors' Addresses 704 Paul Ebersman 705 Comcast 706 One Comcast Center 707 1701 John F. Kennedy Boulevard 708 Philadelphia, PA 19103 709 US 711 Email: ebersman-ietf@dragon.net 712 Chris Griffiths 714 Email: cgriffiths@gmail.com 716 Warren Kumari 717 Google 718 1600 Amphitheatre Parkway 719 Mountain View, CA 94043 720 US 722 Email: warren@kumari.net 723 URI: http://www.google.com 725 Jason Livingood 726 Comcast 727 One Comcast Center 728 1701 John F. Kennedy Boulevard 729 Philadelphia, PA 19103 730 US 732 Email: jason_livingood@cable.comcast.com 733 URI: http://www.comcast.com 735 Ralf Weber 736 Nominum 738 Email: Ralf.Weber@nominum.com 739 URI: http://www.nominum.com