idnits 2.17.1 draft-ietf-dnsop-dnssec-roadblock-avoidance-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2016) is 2812 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP W. Hardaker 3 Internet-Draft Parsons 4 Intended status: Best Current Practice O. Gudmundsson 5 Expires: February 12, 2017 CloudFlare 6 S. Krishnaswamy 7 Parsons 8 August 11, 2016 10 DNSSEC Roadblock Avoidance 11 draft-ietf-dnsop-dnssec-roadblock-avoidance-05.txt 13 Abstract 15 This document describes problems that a Validating DNS resolver, 16 stub-resolver or application might run into within a non-compliant 17 infrastructure. It outlines potential detection and mitigation 18 techniques. The scope of the document is to create a shared approach 19 to detect and overcome network issues that a DNSSEC software/system 20 may face. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 12, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Implementation experiences . . . . . . . . . . . . . . . 4 60 1.3.1. Test Zone Implementation . . . . . . . . . . . . . . 4 61 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Detecting DNSSEC Non-Compliance . . . . . . . . . . . . . . . 5 63 3.1. Determining DNSSEC support in recursive resolvers . . . . 6 64 3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 6 65 3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 6 66 3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 7 67 3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 7 68 3.1.5. Supports the AD bit DNSKEY algorithm 5 and 8 . . . . 7 69 3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 8 70 3.1.7. Supports querying for DNSKEY records . . . . . . . . 8 71 3.1.8. Supports querying for DS records . . . . . . . . . . 8 72 3.1.9. Supports negative answers with NSEC records . . . . . 9 73 3.1.10. Supports negative answers with NSEC3 records . . . . 9 74 3.1.11. Supports queries where DNAME records lead to an 75 answer . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 10 77 3.1.13. Supports Unknown RRtypes . . . . . . . . . . . . . . 10 78 3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 10 79 3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 11 80 3.2.2. Support for Remote UDP With Fragmentation . . . . . . 11 81 3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 11 82 3.3. Support for DNSKEY and DS combinations . . . . . . . . . 12 83 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 12 84 4.1. Resolver capability description . . . . . . . . . . . . . 12 85 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 13 86 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 16 87 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 16 88 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 16 89 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 16 90 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 17 91 7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 18 93 7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 18 94 7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 18 95 7.4. Fails when DNSSEC does not validate . . . . . . . . . . . 18 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 99 11. Normative References . . . . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 This document describes problems observable during DNSSEC ([RFC4034], 105 [RFC4035]) deployment that derive from non-compliant infrastructure. 106 It poses potential detection and mitigation techniques. 108 1.1. Notation 110 In this document a "Host Validator" can either be a validating stub- 111 resolver, such as library that an application has linked in, or a 112 validating resolver daemon running on the same machine. It may or 113 may not be trying to use upstream caching resolvers during its own 114 resolution process; both cases are covered by the tests defined in 115 this document. 117 The sub-variant of this is a "Validating Forwarding Resolver", which 118 is a resolver that is configured to use upstream Resolvers when 119 possible. A Validating Forward Resolver also needs to perform the 120 tests outlined in this document before using an upstream recursive 121 resolver. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 1.2. Background 129 Deployment of DNSSEC validation is hampered by network components 130 that make it difficult or sometimes impossible for validating 131 resolvers to effectively obtain the DNSSEC data they need. This can 132 occur for many different reasons including, but not limited to: 134 o Because recursive resolvers and DNS proxies [RFC5625] are not 135 fully DNSSEC compliant 137 o Because resolvers are not DNSSEC aware 139 o Because "middle-boxes" actively block, modify and/or restrict 140 outbound traffic to the DNS port (53) either UDP and/or TCP . 142 o In-path network components do not allow UDP fragments 143 This document talks about ways that a Host Validator can detect the 144 state of the network it is attached to, and ways to hopefully 145 circumvent the problems associated with the network defects it 146 discovers. The tests described in this document may be performed on 147 any validating resolver to detect and prevent problems. While these 148 recommendations are mainly aimed at Host Validators it it prudent to 149 perform these tests from regular Validating Resolvers before enabling 150 just to make sure things work. 152 There are situations where a host can not talk directly to a 153 Resolver; the tests below can not address how to overcome that, and 154 inconsistent results can be seen in such cases. This can happen, for 155 instance, when there are DNS proxies/forwarders between the user and 156 the actual resolvers. 158 1.3. Implementation experiences 160 Multiple lessons learned from multiple implementations led to the 161 development of this document, including (in alphabetical order) 162 DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, 163 FCC_Grade. 165 Detecting lack of support for specified DNSKEY algorithms and DS 166 digest algorithms is outside the scope of this document but the 167 document provides information on how to do that, see sample test 168 tool: https://github.com/ogud/DNSSEC_ALG_Check 170 This document does describe compliance tests for algorithms 5, 7 and 171 13 with DS digest algorithms 1 and 2. 173 1.3.1. Test Zone Implementation 175 In this document, the "test.example.com" domain is used to refer to 176 DNS records which contain test records that have known DNSSEC 177 properties associated with them. For example, the "badsign- 178 a.test.example.com" domain is used below to refer to a DNS A record 179 where the signatures published for it are invalid (i.e., they are 180 "bad signatures" that should cause a validation failure). 182 At the time of this publication, the "test.dnssec-tools.org" domain 183 implements all of these test records. Thus, it may be possible to 184 replace "test.example.com" in this document with "test.dnssec- 185 tools.org" when performing real-world tests. 187 2. Goals 189 This document is intended to show how a Host Validator can detect the 190 capabilities of a recursive resolver, and work around any problems 191 that could potentially affect DNSSEC resolution. This enables the 192 Host Validator to make use of the caching functionality of the 193 recursive resolver, which is desirable in that it decreases network 194 traffic and improves response times. 196 A Host Validator has two choices: it can wait to determine that it 197 has problems with a recursive resolver based on the results that it 198 is getting from real-world queries issued to it, or it can 199 proactively test for problems (Section 3) to build a work around list 200 ahead of time (Section 5). There are pros and cons to both of these 201 paths that are application specific, and this document does not 202 attempt to provide guidance about whether proactive tests should or 203 should not be used. Either way, DNSSEC roadblock avoidance 204 techniques ought to be used when needed and if possible. 206 Note: Besides being useful for Host Validators, the same tests can be 207 used for a recursive resolver to check if its upstream connections 208 hinder DNSSEC validation. 210 3. Detecting DNSSEC Non-Compliance 212 A Host Validator may choose to determine early-on what roadblocks 213 exist that may hamper its ability to perform DNSSEC look-ups. This 214 section outlines tests that can be done to test certain features of 215 the surrounding network. 217 These tests should be performed when a resolver determines its 218 network infrastructure has changed. Certainly a resolver should 219 perform these tests when first starting, but MAY also perform these 220 tests when they've detected network changes (e.g. address changes, or 221 network reattachment, etc). 223 NOTE: when performing these tests against an address, we make the 224 following assumption about that address: It is a uni-cast address or 225 an any-cast [RFC4786] cluster where all servers have identical 226 configuration and connectivity. 228 NOTE: when performing these tests we also assume that the path is 229 clear of "DNS interfering" middle-boxes, like firewalls, proxies, 230 forwarders. Presence of such infrastructure can easily make a 231 recursive resolver appear to be improperly performing. It is beyond 232 the scope of the document as how to work around such interference, 233 although the tests defined in this document may indicate when such 234 misbehaving middle-ware is causing interference. 236 NOTE: This document specifies two sets of tests to perform: a 237 comprehensive one and a fast one. The fast one will detect most 238 common problems, thus if the fast one passes then the comprehensive 239 MAY be considered passed as well. 241 3.1. Determining DNSSEC support in recursive resolvers 243 Ideally, a Host Validator can make use of the caching present in 244 recursive resolvers. This section discusses the tests that a 245 recursive resolver MUST pass in order to be fully usable as a DNS 246 cache. 248 Unless stated otherwise, all of the following tests SHOULD have the 249 Recursion Desired (RD) flag set when sending out a query and SHOULD 250 be sent over UDP. Unless otherwise stated, the tests MUST NOT have 251 the DO bit set or utilize any of the other DNSSEC related 252 requirements, like EDNS0, unless otherwise specified. The tests are 253 designed to check for support of one feature at a time. 255 3.1.1. Supports UDP answers 257 Purpose: This tests basic DNS over UDP functionality to a resolver. 259 Test: A DNS request is sent to the resolver under test for an A 260 record for a known existing domain, such as good-a.test.example.com. 262 SUCCESS: A DNS response was received that contains an A record in the 263 answer section. (The data itself does not need to be checked.) 265 Note: an implementation MAY chose to not perform the rest of the 266 tests if this test fails, as it is highly unlikely that the resolver 267 under test will pass any of the remaining tests. 269 3.1.2. Supports TCP answers 271 Purpose: This tests basic TCP functionality to a resolver. 273 Test: A DNS request is sent over TCP to the resolver under test for 274 an A record for a known existing domain, such as good- 275 a.test.example.com. 277 SUCCESS: A DNS response was received that contains an A record in the 278 answer section. (The data itself does not need to be checked.) 280 3.1.3. Supports EDNS0 282 Purpose: Test whether a resolver properly supports the EDNS0 283 extension option. 285 Pre-requisite: "Supports UDP or TCP". 287 Test: Send a request to the resolver under test for an A record for a 288 known existing domain, such as good-a.test.example.com, with an EDNS0 289 OPT record in the additional section. 291 SUCCESS: A DNS response was received that contains an EDNS0 option 292 with version number 0. 294 3.1.4. Supports the DO bit 296 Purpose: This tests whether a resolver has minimal support of the DO 297 bit. 299 Pre-requisite: "Supports EDNS0". 301 Test: Send a request to the resolver under test for an A record for a 302 known existing domain such as good-a.test.example.com. Set the DO 303 bit in the outgoing query. 305 SUCCESS: A DNS response was received that contains the DO bit set. 307 Note: this only tests that the resolver sets the DO bit in the 308 response. Later tests will determine if the DO bit was actually made 309 use of. Some resolvers successfully pass this test because they 310 simply copy the unknown flags into the response. These resolvers 311 will fail the later tests. 313 3.1.5. Supports the AD bit DNSKEY algorithm 5 and 8 315 Purpose: This tests whether the resolver is a validating resolver. 317 Pre-requisite: "Supports the DO bit". 319 Test: Send requests to the resolver under test for an A record for a 320 known existing domain in a DNSSEC signed zone which is verifiable to 321 a configured trust anchor, such as good-a.test.example.com using the 322 root's published DNSKEY or DS record as a trust anchor. Set the DO 323 bit in the outgoing query. This test should be done twice, once for 324 a zone that contains algorithm 5 (RSASHA1) and another for algorithm 325 8 (RSASHA256). 327 SUCCESS: A DNS response was received that contains the AD bit set for 328 algorithm 5 (RSASHA1). 330 BONUS: The AD bit is set for a resolver that supports Algorithm 8 331 RSASHA256 333 3.1.6. Returns RRsig for signed answer 335 Purpose: This tests whether a resolver will properly return RRSIG 336 records when the DO bit is set. 338 Pre-requisite: "Supports the DO bit". 340 Test: Send a request to the resolver under test for an A record for a 341 known existing domain in a DNSSEC signed zone, such as good- 342 a.test.example.com. Set the DO bit in the outgoing query. 344 SUCCESS: A DNS response was received that contains at least one RRSIG 345 record. 347 3.1.7. Supports querying for DNSKEY records 349 Purpose: This tests whether a resolver can query for and receive a 350 DNSKEY record from a signed zone. 352 Pre-requisite: "Supports the DO bit." 354 Test: Send a request to the resolver under test for an DNSKEY record 355 which is known to exist in a signed zone, such as test.example.com/ 356 DNSKEY. Set the DO bit in the outgoing query. 358 SUCCESS: A DNS response was received that contains a DNSKEY record in 359 the answer section. 361 Note: Some DNSKEY RRset's are large and if the network path has 362 problems with large answers this query may result in either false 363 positive or false negative. In general the DNSKEY queried for should 364 be small enough to fit into a 1220 byte answer, to avoid false 365 negative result when TCP is disabled. However, querying many zones 366 will result in answers greater than 1220 bytes so DNS over TCP MUST 367 be available for DNSSEC use in general. 369 3.1.8. Supports querying for DS records 371 Purpose: This tests whether a resolver can query for and receive a DS 372 record from a signed zone. 374 Pre-requisite: "Supports the DO bit." 375 Test: Send a request to the resolver under test for an DS record 376 which is known to exist in a signed zone, such as test.example.com/ 377 DS. Set the DO bit in the outgoing query. 379 SUCCESS: A DNS response was received that contains a DS record in the 380 answer section. 382 3.1.9. Supports negative answers with NSEC records 384 Purpose: This tests whether a resolver properly returns NSEC records 385 for a non-existing domain in a DNSSEC signed zone. 387 Pre-requisite: "Supports the DO bit." 389 Test: Send a request to the resolver under test for an A record which 390 is known to not exist in an NSEC signed zone, such as non- 391 existent.test.example.com. Set the DO bit in the outgoing query. 393 SUCCESS: A DNS response was received that contains an NSEC record. 395 Note: The query issued in this test MUST be sent to a NSEC signed 396 zone. Getting back appropriate NSEC3 records does not indicate a 397 failure, but a bad test. 399 3.1.10. Supports negative answers with NSEC3 records 401 Purpose: This tests whether a resolver properly returns NSEC3 records 402 ([RFC5155]) for a non-existing domain in a DNSSEC signed zone. 404 Pre-requisite: "Supports the DO bit." 406 Test: Send a request to the resolver under test for an A record which 407 is known to be non-existent in a zone signed using NSEC3, such as 408 non-existent.nsec3-ns.test.example.com. Set the DO bit in the 409 outgoing query. 411 SUCCESS: A DNS response was received that contains an NSEC3 record. 413 Bonus: If the AD bit is set, this validator supports algorithm 7 414 RSASHA1-NSEC3-SHA1 416 Note: The query issued in this test MUST be sent to a NSEC3 signed 417 zone. Getting back appropriate NSEC records does not indicate a 418 failure, but a bad test. 420 3.1.11. Supports queries where DNAME records lead to an answer 422 Purpose: This tests whether a resolver can query for an A record in a 423 zone with a known DNAME referral for the record's parent. 425 Test: Send a request to the resolver under test for an A record which 426 is known to exist in a signed zone within a DNAME referral child 427 zone, such as good-a.dname-good-ns.test.example.com. 429 SUCCESS: A DNS response was received that contains a DNAME in the 430 answer section. An RRSIG MUST also be received in the answer section 431 that covers the DNAME record. 433 3.1.12. Permissive DNSSEC 435 Purpose: To see if a validating resolver is ignoring DNSSEC 436 validation failures. 438 Pre-requisite: Supports the AD bit. 440 Test: ask for data from a broken DNSSEC delegation such as badsign- 441 a.test.example.com. 443 SUCCESS: A reply was received with the Rcode set to SERVFAIL 445 3.1.13. Supports Unknown RRtypes 447 Purpose: Some DNS Resolvers/gateways only support some RRtypes. This 448 causes problems for applications that need recently defined types. 450 Pre-requisite: "Supports UDP or TCP". 452 Test: Send a request for recently defined type or unknown type in the 453 20000-22000 range, that resolves to a server that will return an 454 answer for all types, such as alltypes.example.com (a server today 455 that supports this: alltypes.res.dnssecready.org) 457 SUCCESS: A DNS response was retrieved that contains the type 458 requested in the answer section. 460 3.2. Direct Network Queries 462 If need be, a Host Validator may need to make direct queries to 463 authoritative servers or known Open Recursive Resolvers in order to 464 collect data. To do that, a number of key network features MUST be 465 functional. 467 3.2.1. Support for Remote UDP Over Port 53 469 Purpose: This tests basic UDP functionality to outside the local 470 network. 472 Test: A DNS request is sent to a known distant authoritative server 473 for a record known to be within that server's authoritative data. 474 Example: send a query to the address of ns1.test.example.com for the 475 good-a.test.example.com/A record. 477 SUCCESS: A DNS response was received that contains an A record in the 478 answer section. 480 Note: an implementation can use the local resolvers for determining 481 the address of the name server that is authoritative for the given 482 zone. The recursive bit MAY be set for this request, but does not 483 need to be. 485 3.2.2. Support for Remote UDP With Fragmentation 487 Purpose: This tests if the local network can receive fragmented UDP 488 answers 490 Pre-requisite: Local UDP traffic > 1500 in size is possible 492 Test: A DNS request is sent over UDP to a known distant DNS address 493 asking for a record that has answer larger than 2000 bytes. For 494 example, send a query for the test.example.com/DNSKEY record with the 495 DO bit set in the outgoing query. 497 Success: A DNS response was received that contains the large answer. 499 Note: A failure in getting large answers over UDP is not a serious 500 problem if TCP is working. 502 3.2.3. Support for Outbound TCP Over Port 53 504 Purpose: This tests basic TCP functionality to outside the local 505 network. 507 Test: A DNS request is sent over TCP to a known distant authoritative 508 server for a record known to be within that server's authoritative 509 data. Example: send a query to the address of ns1.test.example.com 510 for the good-a.test.example.com/A record. 512 SUCCESS: A DNS response was received that contains an A record in the 513 answer section. 515 Note: an implementation can use the local resolvers for determining 516 the address of the name server that is authoritative for the given 517 zone. The recursive bit MAY be set for this request, but does not 518 need to be. 520 3.3. Support for DNSKEY and DS combinations 522 Purpose: These tests can check what algorithm combinations are 523 supported. 525 Pre-requisite: At least one of above tests has returned the AD bit 526 set proving that the upstream is validating 528 Test: A DNS request is sent over UDP to the resolver under test for a 529 known combination of the DS algorithm number (N) and DNSKEY algorithm 530 number (M) of the example form ds-N.alg-M-nsec.test.example.com. 531 Examples: 533 ds-2.alg-13-nsec.test.example.com TXT 534 or 535 ds-4.alg-13-nsec3.test.example.com TXT. 537 SUCCESS: a DNS response is received with the AD bit set and with a 538 matching record type in the answer section. 540 Note: for algorithms 6 and 7, NSEC is not defined thus query for alg- 541 M-nsec3 is required. Similarly NSEC3 is not defined for algorithms 542 1, 3 and 5. Furthermore algorithms 2, 4, 9, 11 do not currently have 543 definitions for signed zones. 545 4. Aggregating The Results 547 Some conclusions can be drawn from the results of the above tests in 548 an "aggregated" form. This section defines some labels to assign to 549 a resolver under test given the results of the tests run against 550 them. 552 4.1. Resolver capability description 554 This section will group and label certain common results 556 Resolvers are classified into following broad behaviors: 558 Validator: The resolver passes all DNSSEC tests and had the AD bit 559 appropriately set. 561 DNSSEC Aware: The resolver passes all DNSSEC tests, but does not 562 appropriately set the AD bit on answers, indicating it is not 563 validating. A Host Validator will function fine using this 564 resolver as a forwarder. 566 Non-DNSSEC capable: The resolver is not DNSSEC aware and will make 567 it hard for a Host Validator to operate behind it. It MAY be 568 usable for querying for data that is in known insecure sections of 569 the DNS tree. 571 Not a DNS Resolver: This is a improperly behaving resolver and not 572 should not be used at all. 574 While it would be great if all resolvers fell cleanly into one of the 575 broad categories above, that is not the case. For that reason it is 576 necessary to augment the classification with more descriptive result, 577 this is done by adding the word "Partial" in front of Validator/ 578 DNSSEC Aware classifications, followed by sub-descriptors of what is 579 not working. 581 Unknown: Failed the Unknown test 583 DNAME: Failed the DNAME test 585 NSEC3: Failed the NSEC3 test 587 TCP: TCP not available 589 SlowBig: UDP is size limited but TCP fallback works 591 NoBig: TCP not available and UDP is size limited 593 Permissive: Passes data known to fail validation 595 5. Roadblock Avoidance 597 The goal of this document is to tie the above tests and aggregations 598 to avoidance practices; however the document does not specify exactly 599 how to do that. 601 Once we have determined what level of support is available in the 602 network, we can determine what must be done in order to effectively 603 act as a validating resolver. This section discusses some of the 604 options available given the results from the previous sections. 606 The general fallback approach can be described by the following 607 sequence: 609 If the resolver is labeled as "Validator" or "DNSSEC aware": 611 Send queries through this resolver and perform local 612 validation on the results. 614 If validation fails, try the next resolver 616 Else if the resolver is labeled "Not a DNS Resolver" or 617 "Non-DNSSEC capable": 619 Mark it as unusable and try next resolver 621 Else if no more resolvers are configured and if direct queries 622 are supported: 624 1. Try iterating from the Root 626 2. If the answer is SECURE/BOGUS: 627 Return the result of the iteration 629 3. If the answer is INSECURE: 630 Re-query "Non-DNSSEC capable" servers and return 631 answers from them w/o the AD bit set to the client. 633 This will increase the likelihood that split-view unsigned 634 answers are found. 636 Else: 638 Return an error code and log a failure 640 While attempting resolution through a particular recursive name 641 server with a particular transport method that worked, any transport- 642 specific parameters MUST be remembered in order to avoid any 643 unnecessary fallback attempts. 645 Transport-specific parameters MUST also be remembered for each 646 authoritative name server that is queried while performing an 647 iterative mode lookup. 649 Any transport settings that are remembered for a particular name 650 server MUST be periodically refreshed; they should also be refreshed 651 when an error is encountered as described below. 653 For a stub resolver, problems with the name server can manifest 654 themselves under the following types of error conditions: 656 o No Response, error response or missing DNSSEC meta-data 658 o Illegal Response: An illegal response is received, which prevents 659 the validator from fetching all necessary records required for 660 constructing an authentication chain. This could result when 661 referral loops are encountered, when any of the antecedent zone 662 delegations are lame, when aliases are erroneously followed for 663 certain RRtypes (such as SOA, DNSKEYs or DS records), or when 664 resource records for certain types (e.g. DS) are returned from a 665 zone that is not authoritative for such records. 667 o Bogus Response: A Bogus Response is received, when the 668 cryptographic assertions in the authentication chain do not 669 validate properly. 671 For each of the above error conditions a validator MAY adopt the 672 following dynamic fallback technique, preferring a particular 673 approach if it is known to work for a given name server or zone from 674 previous attempts. 676 o No response, error response, or missing DNSSEC meta-data: 678 * Re-try with different EDNS0 sizes (4096, 1492, None) 680 * Re-try with TCP only 682 * Perform an iterative query starting from the Root if the 683 previous error was returned from a lookup that had recursion 684 enabled. 686 * Re-try using an alternative transport method, if this 687 alternative method is known (configured) to be supported by the 688 nameserver in question. 690 o Illegal Response 692 * Perform an iterative query starting from the Root if the 693 previous error was returned from a lookup that had recursion 694 enabled. 696 * Check if any of the antecedent zones up to the closest 697 configured trust anchor are provably insecure. 699 o Bogus Response 701 * Perform an iterative query starting from the Root if the 702 previous error was returned from a lookup that had recursion 703 enabled. 705 For each fallback technique, attempts to multiple potential name 706 servers should be skewed such that the next name server is tried when 707 the previous one encounters an error, a timeout is reached, or 708 whichever is earlier. 710 The validator SHOULD remember, in its zone-specific fallback cache, 711 any broken behavior identified for a particular zone for a duration 712 of that zone's SOA negative TTL. 714 The validator MAY place name servers that exhibit broken behavior 715 into a blacklist, and bypass these name servers for all zones that 716 they are authoritative for. The validator MUST time out entries in 717 this name server blacklist periodically, where this interval could be 718 set to be the same as the DNSSEC BAD cache default TTL. 720 5.1. Partial Resolver Usage 722 It may be possible to use Non-DNSSEC Capable caching resolvers in 723 careful ways if maximum optimization is desired. This section 724 describes some of the advanced techniques that could be used to use a 725 resolver in at least a minimal way. Most of the time this would be 726 unnecessary, except in the case where none of the resolvers are fully 727 compliant and thus the choices would be to use them at least 728 minimally or not at all (and no caching benefits would be available). 730 5.1.1. Known Insecure Lookups 732 If a resolver is Non-DNSSEC Capable but a section of the DNS tree has 733 been determined to be Provably Insecure [RFC4035], then queries to 734 this section of the tree MAY be sent through Non-DNSSEC Capable 735 caching resolver. 737 5.1.2. Partial NSEC/NSEC3 Support 739 Resolvers that understand DNSSEC generally, and understand NSEC but 740 not NSEC3 are partially usable. These resolvers generally also lack 741 support for Unknown types, rendering them mostly useless and to be 742 avoided. 744 6. Start-Up and Network Connectivity Issues 746 A number of scenarios will produce either short-term or long-term 747 connectivity issues with respect to DNSSEC validation. Consider the 748 following cases: 750 Time Synchronization: Time synchronization problems can occur when 751 a device which has been off for a period of time and the clock is 752 no longer in close synchronization with "real time" or when a 753 device always has clock set to the same time during start-up. 754 This will cause problems when the device needs to resolve their 755 source of time synchronization, such as "ntp.example.com". 757 Changing Network Properties: A newly established network 758 connection may change state shortly after a HTTP-based pay-wall 759 authentication system has been used. This especially common in 760 hotel, airport and coffee-shop style networks, where DNSSEC, 761 validation and even DNS are not functional until the user proceeds 762 through a series of forced web pages used to enable their network. 763 The tests in Section 3 will produce very different results before 764 and after the network authorization has succeeded. APIs exist on 765 many operating systems to detect initial network device status 766 changes, such as right after DHCP has finished, but few (none?) 767 exist to detect that authentication through a pay-wall has 768 succeeded. 770 There are only two choices when situations like this happen: 772 Continue to perform DNSSEC processing, which will likely result in 773 all DNS requests failing. This is the most secure route, but 774 causes the most operational grief for users. 776 Turn off DNSSEC support until the network proves to be usable. 777 This allows the user to continue using the network, at the 778 sacrifice of security. It also allows for a denial of security- 779 service attack if a man-in-the-middle can convince a device that 780 DNSSEC is impossible. 782 6.1. What To Do 784 If the Host Validator detects that DNSSEC resolution is not possible 785 it SHOULD log the event and/or SHOULD report an error to the user. 786 In the case there is no user, then no reporting can be performed and 787 thus the device MAY have a policy of action, like continue or fail. 788 Until middle boxes allow DNSSEC protected information to traverse 789 them consistently, software implementations may need to offer this 790 choice to let users pick the security level they require. Note that 791 continuing without DNSSEC protection in the absence of a notification 792 or report could lead to situations where users assume a level of 793 security that does not exist. 795 7. Quick Test 797 The quick tests defined below make the assumption that the questions 798 to be asked are of a real resolver and the only real question is: 799 "how complete is the DNSSEC support?". This quick test as been 800 implemented in few programs developed at IETF hackthons at IETF-91 801 and IETF-92. The programs use a common grading method. For each 802 question that returns expected answer the resolver gets a point. If 803 the AD bit is set as expected the resolver gets a second point. 805 7.1. Test negative answers Algorithm 5 807 Query: realy-doesnotexist.test.example.com. A 809 Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC proof 811 7.2. Test Algorithm 8 813 Query: alg-8-nsec3.test.example.com. SOA 815 Answer: RCODE= 0, Answer: SOA record 817 7.3. Test Algorithm 13 819 Query: alg-13-nsec.test.example.com. SOA 821 Answer: RCODE= 0, Answer: SOA record 823 7.4. Fails when DNSSEC does not validate 825 Query: dnssec-failed.test.example.com. SOA 827 Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0 829 8. Security Considerations 831 This document discusses problems that may occur while deploying the 832 DNSSEC protocol. It describes what may be possible to help detect 833 and mitigate these problems. Following the outlined suggestions will 834 result in a more secure DNSSEC operational environment than if DNSSEC 835 was simply disabled. 837 9. IANA Considerations 839 No IANA actions are required. 841 10. Acknowledgments 843 We thank the IESG and DNSOP working group members for their extensive 844 comments and suggestions. 846 11. Normative References 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, March 1997. 851 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 852 Rose, "Resource Records for the DNS Security Extensions", 853 RFC 4034, March 2005. 855 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 856 Rose, "Protocol Modifications for the DNS Security 857 Extensions", RFC 4035, March 2005. 859 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 860 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 861 December 2006, . 863 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 864 Security (DNSSEC) Hashed Authenticated Denial of 865 Existence", RFC 5155, March 2008. 867 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 868 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 869 . 871 Authors' Addresses 873 Wes Hardaker 874 Parsons 875 P.O. Box 382 876 Davis, CA 95617 877 US 879 Email: ietf@hardakers.net 881 Olafur Gudmundsson 882 CloudFlare 883 San Francisco, CA 94107 884 USA 886 Email: olafur+ietf@cloudflare.com 887 Suresh Krishnaswamy 888 Parsons 889 7110 Samuel Morse Dr 890 Columbia, MD 21046 891 US 893 Email: suresh@tislabs.com