idnits 2.17.1 draft-ietf-dnsop-dnssec-roadblock-avoidance-00.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 13 instances 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 (March 07, 2014) is 3696 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: September 08, 2014 Shinkuro Inc. 6 S. Krishnaswamy 7 Parsons 8 March 07, 2014 10 DNSSEC Roadblock Avoidance 11 draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt 13 Abstract 15 This document describes problems that a DNSSEC aware resolver/ 16 application might run into within a non-compliant infrastructure. It 17 outline potential detection and mitigation techniques. The scope of 18 the document is to create a shared approache to detect and overcome 19 network issues that a DNSSEC software/system may face. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 08, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 4 60 3.1. Determining DNSSEC support in neighboring recursive 61 resolvers . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 4 63 3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 5 64 3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 5 65 3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 5 66 3.1.5. Supports the AD bit . . . . . . . . . . . . . . . . . 6 67 3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 6 68 3.1.7. Supports querying for DNSKEY records . . . . . . . . 6 69 3.1.8. Supports querying for DS records . . . . . . . . . . 7 70 3.1.9. Supports negative answers with NSEC records . . . . . 7 71 3.1.10. Supports negative answers with NSEC3 records . . . . 7 72 3.1.11. Supports queries where DNAME records lead to an 73 answer . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 8 75 3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 8 76 3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 8 77 3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 9 78 3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 9 79 3.2.2. Support for Remote UDP With Fragmentation . . . . . . 9 80 3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 10 81 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 10 82 4.1. Resolver capability description . . . . . . . . . . . . . 10 83 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 11 84 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 13 85 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 13 86 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 14 87 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 14 88 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 14 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 92 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 96 This document describes problems with DNSSEC ([RFC4034], [RFC4035]) 97 deployment due to non-compliant infrastructure. It poses potential 98 detection and mitigation techniques. 100 1.1. Background 102 Deployment of DNSSEC today is hampered by network components that 103 make it difficult or sometimes impossible for validating resolvers to 104 effectively obtain the DNSSEC data they need. This can occur for 105 many different reasons including 107 o Because neighboring recursive resolvers are not fully DNSSEC 108 compliant 110 o Because resolvers are not even DNSSEC aware 112 o Because "middle-boxes" active block/restrict outbound traffic to 113 the DNS port (53) either UDP and/or TCP . 115 o Network component in path does not allow UDP fragments 117 o etc... 119 This document talks about ways a Host Validator can detect the state 120 of the network it is attached to, and ways to hopefully circumvent 121 the problems associated with the network defects it discovers. The 122 tests described in this document may be performed on any validating 123 resolver to detect and prevent problems. While these recomendations 124 are mainly aimed at Host Validators it it prudent to perform these 125 test from regular Validatating Resolvers before enabling just to make 126 sure things work. 128 1.2. Notation 130 When we talk about a "Host Validator", this can either be a library 131 that an application has linked in or an actual validating resolver 132 running on the same machine. 134 A variant of this is a "Validating Forwarding Resolver", which is a 135 resolver that is configured to use upstream Resolvers if possible. 136 Validating Forward Resolver needs to perform the same set of tests 137 before using an upstream recursive resolver. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Goals 145 The result of this work is intended to show how a Host Validator can 146 detect the capabilities of a nearby recursive resolver, and work 147 around any problems that could potentially affect DNSSEC resolution. 148 This enables the Host Validator to make use of the caching 149 functionality of the recursive resolver, which is desirable in that 150 it decreases network traffic and improves response times. 152 A Host Validator has two choices: it can wait to determine that it 153 has problems with a recursive resolver based on the results that it 154 is getting from real-world queries issued to it, or it can 155 proactively test for problems (Section Section 3) to build a work 156 around list ahead of time (Section Section 5). There are pros and 157 cons to both of these paths that are application specific, and this 158 document does not attempt to provide guidance about whether proactive 159 tests should or should not be used. Either way, DNSSEC roadblock 160 avoidance techniques ought to be used when needed and if possible. 162 3. Detecting DNSSEC Non-Compilance 164 A Host Validator may choose to determine early-on what bottlenecks 165 exist that may hamper its ability to perform DNSSEC look-ups. This 166 section outlines tests that can be done to test certain features of 167 the surrounding network. 169 NOTE: when performing these tests against an address, we make the 170 following assumtption about that address: It is a unicast address or 171 an anycast cluster where all servers have identical configuration and 172 connectivity. 174 3.1. Determining DNSSEC support in neighboring recursive resolvers 176 Ideally, a Host Validator can make use of the caching present in 177 neighboring recursive resolvers. This section discusses the tests 178 that a neighboring recursive resolver MUST pass in order to be fully 179 usable as a near-by DNS cache. 181 Unless stated otherwise, all of the following tests SHOULD have the 182 recursive flag set when sending out a query and SHOULD be sent over 183 UDP. Unless otherwise stated, the tests MUST NOT have the DO bit set 184 or utilize any of the other DNSSEC related requirements, like EDNS0. 185 The tests are designed to check for one feature at a time. 187 3.1.1. Supports UDP answers 189 Purpose: This tests basic DNS over UDP functionality to a resolver. 191 Test: A DNS request is sent to the resolver under test for an A 192 record for a known existing domain, such as www.dnssec-tools.org. 194 SUCCESS: A DNS response was received that contains an a A record in 195 the answer section. (The data itself does not need to be checked.) 197 Note: an implementation MAY chose to not perform the rest of the 198 tests if this test fails, as clearly the resolver under test is 199 severely broken. 201 3.1.2. Supports TCP answers 203 Purpose: This tests basic TCP functionality to a resolver. 205 Test: A DNS request is sent over TCP to the resolver under test for 206 an A record for a known existing domain, such as www.dnssec- 207 tools.org. 209 SUCCESS: A DNS response was received that contains an A record in the 210 answer section. (The data itself does not need to be checked.) 212 3.1.3. Supports EDNS0 214 Purpose: Test whether a resolver properly supports the EDNS0 215 extension option. 217 Pre-requisite: "Supports UDP or TCP". 219 Test: Send a request to the resolver under test for an A record for a 220 known existing domain, such as www.dnssec-tools.org, with an EDNS0 221 OPT record in the additional section. 223 SUCCESS: A DNS response was received that contains an EDNS0 option 224 with version number 0. 226 3.1.4. Supports the DO bit 228 Purpose: This tests whether a resolver has minimal support of the DO 229 bit. 231 Pre-requisite: "Supports EDNS0". 233 Test: Send a request to the resolver under test for an A record for a 234 known existing domain such as www.dnssec-tools.org. Set the DO bit 235 in the outgoing query. 237 SUCCESS: A DNS response was received that contains the DO bit set. 239 Note: this only tests that the resolver sets the DO bit in the 240 response. Later checks will determine if the DO bit was actually 241 made use of. Some resolvers successfully pass this test because they 242 simply copy the unknown flags into the response. Don't worry, 243 they'll fail the later tests. 245 3.1.5. Supports the AD bit 247 Purpose: This tests whether the resolver is a validating resolver. 249 Pre-requisite: "Supports the DO bit". 251 Test: Send a request to the resolver under test for an A record for a 252 known existing domain in a DNSSEC signed zone which is verifiable to 253 a configured trust anchor, such as www.dnssec-tools.org using the 254 root's published DNSKEY or DS record as a trust anchor. Set the DO 255 bit in the outgoing query. 257 SUCCESS: A DNS response was received that contains the AD bit set. 259 3.1.6. Returns RRsig for signed answer 261 Purpose: This tests whether a resolver will properly return RRSIG 262 records when the DO bit is set. 264 Pre-requisite: "Supports the DO bit". 266 Test: Send a request to the resolver under test for an A record for a 267 known existing domain in a DNSSEC signed zone, such as www.dnssec- 268 tools.org. Set the DO bit in the outgoing query. 270 SUCCESS: A DNS response was received that contains at least one RRSIG 271 record. 273 3.1.7. Supports querying for DNSKEY records 275 Purpose: This tests whether a resolver can query for and receive a 276 DNSKEY record from a signed zone. 278 Pre-requisite: "Supports the DO bit." 280 Test: Send a request to the resolver under test for an DNSKEY record 281 which is known to exist in a signed zone, such as dnssec-tools.org/ 282 DNSKEY. Set the DO bit in the outgoing query. 284 SUCCESS: A DNS response was received that contains a DNSKEY record in 285 the answer section. 287 Note: Some DNSKEY RRset's are large and if the network path has 288 problems with large answers this query may result in either false 289 positive or false negative. In general the DNSKEY queried for is a 290 small enough to fit into 1220 byte answer, to avoid false negative 291 result when TCP is disabled. However, querying many zones will 292 result in answers greater than 1220 bytes so ideally TCP MUST be 293 available. 295 3.1.8. Supports querying for DS records 297 Purpose: This tests whether a resolver can query for and receive a DS 298 record from a signed zone. 300 Pre-requisite: "Supports the DO bit." 302 Test: Send a request to the resolver under test for an DS record 303 which is known to exist in a signed zone, such as dnssec-tools.org/ 304 DS. Set the DO bit in the outgoing query. 306 SUCCESS: A DNS response was received that contains a DS record in the 307 answer section. 309 3.1.9. Supports negative answers with NSEC records 311 Purpose: This tests whether a resolver properly returns NSEC records 312 for a non-existing domain in a DNSSEC signed zone. 314 Pre-requisite: "Supports the DO bit." 316 Test: Send a request to the resolver under test for an A record which 317 is known to not existing, such as non-existent.test.dnssec-tools.org. 318 Set the DO bit in the outgoing query. 320 SUCCESS: A DNS response was received that contains an NSEC record. 322 Note: The query issued in this test MUST be sent to a NSEC signed 323 zone. Getting back appropriate NSEC3 records does not indicate a 324 failure, but a bad test. 326 3.1.10. Supports negative answers with NSEC3 records 328 Purpose: This tests whether a resolver properly returns NSEC3 records 329 ([RFC5155]) for a non-existing domain in a DNSSEC signed zone. 331 Pre-requisite: "Supports the DO bit." 332 Test: Send a request to the resolver under test for an A record which 333 is known to be non-existent, such as non-existent.nsec3-ns.test 334 .dnssec-tools.org. Set the DO bit in the outgoing query. 336 SUCCESS: A DNS response was received that contains an NSEC3 record. 338 Note: The query issued in this test MUST be sent to a NSEC3 signed 339 zone. Getting back appropriate NSEC records does not indicate a 340 failure, but a bad test. 342 3.1.11. Supports queries where DNAME records lead to an answer 344 Purpose: This tests whether a resolver can query for an A record in a 345 zone with a known DNAME referral for the record's parent. 347 Test: Send a request to the resolver under test for an A record which 348 is known to exist in a signed zone within a DNAME referral child 349 zone, such as good-a.dname-good-ns.test.dnssec-tools.net. 351 SUCCESS: A DNS response was received that contains a DNAME in the 352 answer section. An RRSIG MUST also be received in the answer section 353 that covers the DNAME record. 355 3.1.12. Permissive DNSSEC 357 Purpose: To see if a validating resolver is ignoring DNSSEC 358 validation failures. 360 Pre-requisite: Supports the AD bit. 362 Test: ask for data from a broken DNSSEC delegation such as 363 badsign-a.test.dnssec-tools.org. 365 SUCCESS: A reply with the Rcode set to SERVFAIL 367 3.1.13. UDP size limits 369 TBD 371 3.1.14. Supports Unknown RRtypes 373 Purpose: Some DNS Resolvers/gateways only support some RRtypes. This 374 causes problems for applications that need recently defined types. 376 Pre-requisite: "Supports UDP or TCP". 378 Test: Send a request for recently defined type or unknown type in the 379 20000-22000 range, that resolves to a server that will return answer 380 for all types, such as alltypes.res.dnssecready.org 382 SUCCESS: A DNS response was retrieved that contains the type 383 requested in the answer section. 385 3.2. Direct Network Queries 387 If need be, a Host Validator may need to make direct queries to 388 authoritative servers or known Open Recursive Resolvers in order to 389 collect data. To do that, a number of key network features MUST be 390 functional. 392 3.2.1. Support for Remote UDP Over Port 53 394 Purpose: This tests basic UDP functionality to outside the local 395 network. 397 Test: A DNS request is sent to a known distant authoritative server 398 for a record known to be within that server's authoritative data. 399 Example: send a query to the address of ns1.dnssec-tools.org for the 400 www.dnssec-tools.org/A record. 402 SUCCESS: A DNS response was received that contains an a A record in 403 the answer section. 405 Note: an implementation can use the local resolvers for determining 406 the address of the name server that is authoritative for the given 407 zone. The recursive bit MAY be set for this request, but does not 408 need to be. 410 3.2.2. Support for Remote UDP With Fragmentation 412 Purpose: This tests if the local network can receive fragmented UDP 413 answers 415 Pre-requisite: Local UDP > 1500 is possible 417 Test: A DNS request is sent over UDP to a known distant DNS address 418 asking for a record that has answer larger than 2000 bytes. Example 419 send a query for the dnssec-tools.org/DNSKEY record with the DO bit 420 set in the outgoing query. 422 Success: A DNS response was received that contains the large answer. 424 Note: A failure in getting large answers over UDP is not a serious 425 problem if TCP is working. 427 3.2.3. Support for Outbound TCP Over Port 53 429 Purpose: This tests basic TCP functionality to outside the local 430 network. 432 Test: A DNS request is sent over TCP to a known distant authoritative 433 server for a record known to be within that server's authoritative 434 data. Example: send a query to the address of ns1.dnssec-tools.org 435 for the www.dnssec-tools.org/A record. 437 SUCCESS: A DNS response was received that contains an a A record in 438 the answer section. 440 Note: an implementation can used the local resolvers for determining 441 the address of the name server that is authoritative for the given 442 zone. The recursive bit MAY be set for this request, but does not 443 need to be. 445 4. Aggregating The Results 447 Some conclusions can be drawn from the results of the above tests in 448 an "aggregated" form. This section defines some labels to assign to 449 a resolver under test given the results of the tests run against 450 them. 452 4.1. Resolver capability description 454 This section will group and label certain common results TBD 456 Resolvers are classified into following broad behaviors: 458 Validator: The resolver passes all DNSSEC tests and had the AD bit 459 appropriately set. 461 DNSSEC Aware: The resolver passes all DNSSEC tests, but does not 462 appropriately set the AD bit on answers, indicating it is not 463 validating. A Host Validator will function fine using this 464 resolver as a forwarder. 466 Non-DNSSEC capable: The resolver is not DNSSEC aware and will make 467 it hard for a Host Validator to operate behind it. It MAY be 468 usable for querying for data that is in known insecure sections of 469 the DNS tree. 471 Not a DNS Resolver: This is a bad address and not used anymore. 473 While it would be great if all resolvers fell cleanly into one of the 474 broad categories above, that is not the case. For that reason it is 475 necessary to augment the classification with more descriptive result, 476 this is done by adding the word "Partial" in front of Validator/ 477 DNSSEC Aware classifications, followed by sub-descriptors of what is 478 not working. 480 Unknown: Failed Unknown test 482 DNAME: Failed DNAME test 484 NSEC3: Failed NSEC3 test 486 TCP: TCP not available 488 SlowBig: UDP is size limited but TCP fallback works 490 NoBig: TCP not available and UDP is size limited 492 Permissive: Passes data known to fail validation 494 5. Roadblock Avoidance 496 [Editors note: the goal of this document is to tie the above tests 497 and aggregations to avoidance practices; however right now the "tie" 498 part of this text is known to be weak. The goal of this document is 499 specifically to improve this tie as work on this document progresses] 501 Once we have determined what level of support is available in the 502 neighboring network, we can determine what MUST be done in order to 503 effectively act as a validating resolver. This section discusses 504 some of the options available given the results from the previous 505 sections. 507 The general fallback approach can be described by the following 508 sequence: 510 If the resolver is labeled as "Validator" or "DNSSEC aware" 512 Send query through this resolver and perform local 513 validation on the results. 515 If validation fails, try the next resolver 517 Else if the resolver is labeled "Not a DNS Resolver" or 518 "Non-DNSSEC capable" 520 Mark it as unusable and try next resolver 522 Else if no more resolvers are configured and if direct queries 523 are supported try iterating from Root 525 Else return a useful error code 527 While attempting resolution through a particular recursive name 528 server with a particular transport method that worked, any transport- 529 specific parameters MUST be remembered in order to short-circuit any 530 unnecessary fallback attempts. 532 Transport-specific parameters MUST also be remembered for each 533 authoritative name server that is queried while performing an 534 iterative mode lookup. 536 Any transport settings that are remembered for a particular name 537 server MUST be periodically refreshed; they should also be refreshed 538 when an error is encountered as described below. 540 For a stub resolver, problems with the name server MAY manifest 541 themselves as the following types of error conditions: 543 o No response/error response or missing DNSSEC meta-data. 545 o Illegal Response, which prevents the validator from fetching all 546 necessary records required for constructing an authentication 547 chain. This could result when referral loops are encountered, 548 when any of the antecedent zone delegations are lame, when aliases 549 are erroneously followed for certain RRtypes (such as SOA, DNSKEYs 550 or DS records), or when resource records for certain types (e.g. 551 DS) are returned from a zone that is not authoritative for such 552 records. 554 o Bogus Response, when the cryptographic assertions in the 555 authentication chain do not validate properly. 557 For each of the above error conditions a validator MAY adopt the 558 following dynamic fallback technique, preferring a particular 559 approach if it is known to work for a given name server or zone from 560 previous attempts. 562 o No response, error response, or missing DNSSEC meta-data 564 * Re-try with different EDNS0 sizes (4096, 1492, None) 566 * Re-try with TCP only 567 * Perform an iterative query starting from Root if the previous 568 error was returned from a lookup that had recursion enabled. 570 * Re-try using an alternative transport method, if this 571 alternative method is known (configured) to be supported by the 572 nameserver in question. 574 o Illegal Response 576 * Perform an iterative query starting from Root if the previous 577 error was returned from a lookup that had recursion enabled. 579 * Check if any of the antecedent zones up to the closest 580 configured trust anchor are provably insecure. 582 o Bogus Response 584 * Perform an iterative query starting from Root if the previous 585 error was returned from a lookup that had recursion enabled. 587 For each fallback technique, attempts to multiple potential name 588 servers should be skewed such that the next name server is tried when 589 the previous one encounters an error or a timeout is reached, 590 whichever is earlier. 592 The validator SHOULD remember, in its zone-specific fallback cache, 593 any broken behavior identified for a particular zone for a duration 594 of that zone's SOA negative TTL. 596 The validator MAY place name servers that exhibit broken behavior 597 into a blacklist, and bypass these name servers for all zones that 598 they are authoritative for. The validator MUST time out entries in 599 this name server blacklist periodically, where this interval could be 600 set to be the same as the DNSSEC BAD cache default TTL. 602 5.1. Partial Resolver Usage 604 It MAY be possible to use Non-DNSSEC Capable caching resolvers in 605 careful ways if maximum optimization is desired. This section 606 describes some of the advanced techniques that could be used to use a 607 resolver in at least a minimal way. Most of the time this would be 608 unnecessary, except in the case where none of the resolvers are fully 609 compliant and thus the choices would be to use them at least 610 minimally or not at all (and no caching benefits would be available). 612 5.1.1. Known Insecure Lookups 613 If a resolver is Non-DNSSEC Capable but a section of the DNS tree has 614 been determined to be Provably Insecure [RFC4035], then queries to 615 this section of the tree MAY be sent through Non-DNSSEC Capable 616 caching resolver. 618 5.1.2. Partial NSEC/NSEC3 Support 620 TBD 622 6. Start-Up and Network Connectivity Issues 624 A number of scenarios will produce either short-term or long-term 625 connectivity issues with respect to DNSSEC validation. Consider the 626 following cases: 628 Time Synchronization: Time synchronization problems can occure 629 when a device which has been off for a period of time and the 630 clock is no longer in close synchronization with "real time" or 631 when a device always has clock set to the same time during start- 632 up. This will cause problems when the device needs to resolve 633 their source of time synchronization, such as "ntp.example.com". 635 Changing Network Properties: A newly established network 636 connection MAY change state shortly after a HTTP-based pay-wall 637 authentication system has been used. This especially common in 638 hotel networks, where DNSSEC, validation and even DNS are not 639 functional until the user proceeds through a series of forced web 640 pages used to enable their network. The tests in 641 Section Section 3 will produce very different results before and 642 after the network authorization has succeeded. APIs exist on many 643 operating systems to detect initial network device status changes, 644 such as right after DHCP has finished, but few (none?) exist to 645 detect that authentication through a pay-wall has succeeded. 647 There are only two choices when situations like this happen: 649 Continue to perform DNSSEC processing, which will likely result in 650 all DNS requests failing. This is the most secure route, but 651 causes the most operational grief for users. 653 Turn off DNSSEC support until the network proves to be usable. 654 This allows the user to continue using the network, at the 655 sacrifice of security. It also allows for a denial of security- 656 service attack if a man-in-the-middle can convince a device that 657 DNSSEC is impossible. 659 6.1. What To Do 660 TBD 662 7. IANA Considerations 664 No IANA actions are require to support this document 666 8. Security Considerations 668 This document discusses problems that may occur while deploying the 669 secure DNSSEC protocol and what mitigation's can be used to help 670 detect and mitigate these problems. Following these suggestions will 671 result in a more secure DNSSEC operational environment than if DNSSEC 672 was simply disabled when it fails to perform as expected. 674 9. Acknowledgments 676 Multiple lessons learned from multiple implementations led to the 677 development of this document, including (in alphabetical order) 678 DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, 679 FCC_Grade. 681 The following people contributed to portions of this document in some 682 fashion: .... 684 10. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 690 Rose, "Resource Records for the DNS Security Extensions", 691 RFC 4034, March 2005. 693 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 694 Rose, "Protocol Modifications for the DNS Security 695 Extensions", RFC 4035, March 2005. 697 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 698 Security (DNSSEC) Hashed Authenticated Denial of 699 Existence", RFC 5155, March 2008. 701 Authors' Addresses 702 Wes Hardaker 703 Parsons 704 P.O. Box 382 705 Davis, CA 95617 706 US 708 Email: ietf@hardakers.net 710 Olafur Gudmundsson 711 Shinkuro Inc. 712 4922 Fairmont Av, Suite 250 713 Bethesda, MD 20814 714 USA 716 Email: ogud@ogud.com 718 Suresh Krishnaswamy 719 Parsons 720 7110 Samuel Morse Dr 721 Columbia, MD 21046 722 US 724 Email: suresh@tislabs.com