idnits 2.17.1 draft-ietf-dnsext-forgery-resilience-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2181, updated by this document, for RFC5378 checks: 1996-02-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2008) is 5573 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions (DNSEXT) A. Hubert 3 Internet-Draft Netherlabs Computer Consulting BV. 4 Updates: 2181 (if approved) R. van Mook 5 Intended status: Standards Track Equinix 6 Expires: June 18, 2009 December 15, 2008 8 Measures for making DNS more resilient against forged answers 9 draft-ietf-dnsext-forgery-resilience-10.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 18, 2009. 34 Copyright Notice 36 Copyright (c) 2008 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The current Internet climate poses serious threats to the Domain Name 49 System. In the interim period before the DNS protocol can be secured 50 more fully, measures can already be taken to harden the DNS to make 51 'spoofing' a recursing nameserver many orders of magnitude harder. 53 Even a cryptographically secured DNS benefits from having the ability 54 to discard bogus responses quickly, as this potentially saves large 55 amounts of computation. 57 By describing certain behaviour that has previously not been 58 standardised, this document sets out how to make the DNS more 59 resilient against accepting incorrect responses. This document 60 updates RFC 2181. 62 Table of Contents 64 1. Requirements and definitions . . . . . . . . . . . . . . . . . 4 65 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7 69 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8 70 4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Matching the question section . . . . . . . . . . . . . . 9 72 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 9 73 4.4. Matching the source address of the authentic response . . 9 74 4.5. Matching the destination address and port of the 75 authentic response . . . . . . . . . . . . . . . . . . . . 9 76 4.6. Have the response arrive before the authentic response . . 10 77 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Accepting only in-domain records . . . . . . . . . . . . . . . 13 79 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 14 81 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 15 82 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8.1. Repetitive spoofing attempts for a single domain name . . 17 84 9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 18 85 9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 18 86 9.2. Extending the Q-ID space by using ports and addresses . . 18 87 9.2.1. Justification and Discussion . . . . . . . . . . . . . 19 88 9.3. Spoof detection and countermeasure . . . . . . . . . . . . 19 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Requirements and definitions 99 1.1. Definitions 101 This document uses the following definitions: 103 Client: typically a 'stub-resolver' on an end-user's computer 105 Resolver: a nameserver performing recursive service for clients, 106 also known as a caching server, or a full service resolver 107 ([RFC1123], paragraph 6.1.3.1) 109 Stub resolver: a very limited Resolver on a client computer, that 110 leaves the recursing work to a full resolver 112 Query: a question sent out by a resolver, typically in a UDP 113 packet 115 Response: the answer sent back by an authoritative nameserver, 116 typically in a UDP packet 118 Third party: any entity other than the resolver or the intended 119 recipient of a question. The third party may have access to an 120 arbitrary authoritative nameserver, but has no access to packets 121 transmitted by the Resolver or authoritative server 123 Attacker: malicious third party. 125 Spoof: the activity of attempting to subvert the DNS process by 126 getting a chosen answer accepted 128 Authentic response: the correct answer that comes from the right 129 authoritative server 131 Target domain name: domain for which the attacker wishes to spoof 132 in an answer 134 Fake data: response chosen by the attacker 136 1.2. Key words 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Introduction 144 This document describes several common problems in DNS 145 implementations which, although previously recognized, remain largely 146 unsolved. Besides briefly recapping these problems, this document 147 contains rules that, if implemented, make complying resolvers vastly 148 more resistant to the attacks described. The goal is to make the 149 existing DNS as secure as possible within the current protocol 150 boundaries. 152 The words below are aimed at authors of resolvers: it is up to 153 operators to decide which nameserver implementation to use, or which 154 options to enable. Operational constraints may override the security 155 concerns described below. However, implementations are expected to 156 allow an operator to enable functionality described in this document. 158 Almost every transaction on the Internet involves the Domain Name 159 System, which is described in [RFC1034], [RFC1035] and beyond. 161 Additionally, it has recently become possible to acquire SSL/TLS 162 certificates with no other confirmation of identity than the ability 163 to respond to a verification email sent via SMTP ([RFC2821]) - which 164 generally uses DNS for its routing. 166 In other words, any party that (temporarily) controls the Domain Name 167 System is in a position to reroute most kinds of Internet 168 transactions, including the verification steps in acquiring an SSL/ 169 TLS certificate for a domain. This in turn means that even 170 transactions protected by SSL/TLS could be diverted. 172 It is entirely conceivable that such rerouted traffic could be used 173 to the disadvantage of Internet users. 175 These and other developments have made the security and 176 trustworthiness of DNS of renewed importance. Although the DNS 177 community is working hard on finalising and implementing a 178 cryptographically enhanced DNS protocol, steps should be taken to 179 make sure that the existing use of DNS is as secure as possible 180 within the bounds of the relevant standards. 182 It should be noted that the most commonly used resolvers currently do 183 not perform as well as possible in this respect, making this document 184 of urgent importance. 186 A thorough analysis of risks facing DNS can be found in [RFC3833]. 188 This document expands on some of the risks mentioned in RFC 3833, 189 especially those outlined in the sections on 'ID Guessing and Query 190 Prediction' and 'Name Chaining'. Furthermore, it emphasises a number 191 of existing rules and guidelines embodied in the relevant DNS 192 protocol specifications. The following also specifies new 193 requirements to make sure the Domain Name System can be relied upon 194 until a more secure protocol has been standardised and deployed. 196 It should be noted that even when all measures suggested below are 197 implemented, protocol users are not protected against third parties 198 with the ability to observe, modify or inject packets in the traffic 199 of a resolver. 201 For protocol extensions that offer protection against these 202 scenarios, see [RFC4033] and beyond. 204 3. Description of DNS spoofing 206 When certain steps are taken it is feasible to 'spoof' the current 207 deployed majority of resolvers with carefully crafted and timed DNS 208 packets. Once spoofed, a caching server will repeat the data it 209 wrongfully accepted, and make its clients contact the wrong, and 210 possibly malicious, servers. 212 To understand how this process works it is important to know what 213 makes a resolver accept a response. 215 The following sentence in section 5.3.3 of [RFC1034] presaged the 216 present problem: 218 The resolver should be highly paranoid in its parsing of responses. 219 It should also check that the response matches the query it sent 220 using the ID field in the response. 222 DNS data is to be accepted by a resolver if and only if: 224 1. The question section of the reply packet is equivalent to that of 225 a question packet currently waiting for a response 227 2. The ID field of the reply packet matches that of the question 228 packet 230 3. The response comes from the same network address the question was 231 sent to 233 4. The response comes in on the same network address, including port 234 number, as the question was sent from 236 In general, the first response matching these four conditions is 237 accepted. 239 If a third party succeeds in meeting the four conditions before the 240 response from the authentic nameserver does so, it is in a position 241 to feed a resolver fabricated data. When it does so, we dub it an 242 attacker, attempting to spoof in fake data. 244 All conditions mentioned above can theoretically be met by a third 245 party, with the difficulty being a function of the resolver 246 implementation and zone configuration. 248 4. Detailed Description of Spoofing Scenarios 250 The previous paragraph discussed a number of requirements an attacker 251 must match in order to spoof in manipulated (or fake) data. This 252 section discusses the relative difficulties and how implementation 253 defined choices impact the amount of work an attacker has to perform 254 to meet said difficulties. 256 Some more details can be found in section 2.2 of [RFC3833]. 258 4.1. Forcing a query 260 Formally, there is no need for a nameserver to perform service except 261 for its operator, its customers or more generally its users. 262 Recently, open recursing nameservers have been used to amplify denial 263 of service attacks. 265 Providing full service enables the third party to send the target 266 resolver a query for the domain name it intends to spoof. On 267 receiving this query, and not finding the answer in its cache, the 268 resolver will transmit queries to relevant authoritative nameservers. 269 This opens up a window of opportunity for getting fake answer data 270 accepted. 272 Queries may however be forced indirectly, for example by inducing a 273 mail server to perform DNS lookups. 275 Some operators restrict access by not recursing for unauthorised IP 276 addresses, but only respond with data from the cache. This makes 277 spoofing harder for a third party as it cannot then force the exact 278 moment a question will be asked. It is still possible however to 279 determine a time range when this will happen, because nameservers 280 helpfully publish the decreasing TTL of entries in the cache, which 281 indicate from which absolute time onwards a new query could be sent 282 to refresh the expired entry. 284 The time to live of the target domain name's RRSets determines how 285 often a window of opportunity is available, which implies that a 286 short TTL makes spoofing far more viable. 288 Note that the attacker might very well have authorised access to the 289 target resolver by virtue of being a customer or employee of its 290 operator. In addition, access may be enabled through the use of 291 reflectors as outlined in [RFC5358]. 293 4.2. Matching the question section 295 DNS packets, both queries and responses, contain a question section. 296 Incoming responses should be verified to have a question section that 297 is equivalent to that of the outgoing query. 299 4.3. Matching the ID field 301 The DNS ID field is 16 bits wide, meaning that if full use is made of 302 all these bits, and if their contents are truly random, it will 303 require on average 32768 attempts to guess. Anecdotal evidence 304 suggests there are implementations utilising only 14 bits, meaning on 305 average 8192 attempts will suffice. 307 Additionally, if the target nameserver can be forced into having 308 multiple identical queries outstanding, the 'Birthday Attack' 309 phenomenon means that any fake data sent by the attacker is matched 310 against multiple outstanding queries, significantly raising the 311 chance of success. Further details in Section 5. 313 4.4. Matching the source address of the authentic response 315 It should be noted that meeting this condition entails being able to 316 transmit packets on behalf of the address of the authoritative 317 nameserver. While two Best Current Practice documents ([RFC2827] and 318 [RFC3013] specifically) direct Internet access providers to prevent 319 their customers from assuming IP addresses that are not assigned to 320 them, these recommendations are not universally (nor even widely) 321 implemented. 323 Many zones have two or three authoritative nameservers, which make 324 matching the source address of the authentic response very likely 325 with even a naive choice having a double digit success rate. 327 Most recursing nameservers store relative performance indications of 328 authoritative nameservers, which may make it easier to predict which 329 nameserver would originally be queried - the one most likely to 330 respond the quickest. 332 Generally, this condition requires at most two or three attempts 333 before it is matched. 335 4.5. Matching the destination address and port of the authentic 336 response 338 Note that the destination address of the authentic response is the 339 source address of the original query. 341 The actual address of a recursing nameserver is generally known; the 342 port used for asking questions is harder to determine. Most current 343 resolvers pick an arbitrary port at startup (possibly at random) and 344 use this for all outgoing queries. In quite a number of cases the 345 source port of outgoing questions is fixed at the traditional DNS 346 assigned server port number of 53. 348 If the source port of the original query is random, but static, any 349 authoritative nameserver under observation by the attacker can be 350 used to determine this port. This means that matching this 351 conditions often requires no guess work. 353 If multiple ports are used for sending queries, this enlarges the 354 effective ID space by a factor equal to the number of ports used. 356 Less common resolving servers choose a random port per outgoing 357 query. If this strategy is followed, this port number can be 358 regarded as an additional ID field, again containing up to 16 bits. 360 If the maximum ports range is utilized, on average, around 32256 361 source ports would have to be tried before matching the source port 362 of the original query as ports below 1024 may be unavailable for use, 363 leaving 64512 options. 365 It is in general safe for DNS to use ports in the range 1024-49152 366 even though some of these ports are allocated to other protocols. 367 DNS resolvers will not be able to use any ports that are already in 368 use. If a DNS resolver uses a port it will release that port after a 369 short time and migrate to a different port. Only in the case of high 370 volume resolver is it possible that an application wanting a 371 particular UDP port suffers a long term block-out. 373 It should be noted that a firewall will not prevent the matching of 374 this address, as it will accept answers that (appear) to come from 375 the correct address, offering no additional security. 377 4.6. Have the response arrive before the authentic response 379 Once any packet has matched the previous four conditions (plus 380 possible additional conditions), no further responses are generally 381 accepted. 383 This means that the third party has a limited time in which to inject 384 its spoofed response. For calculations we will assume a window in 385 order of at most 100ms (depending on the network distance to the 386 authentic authoritative nameserver). 388 This time period can be far longer if the authentic authoritative 389 nameservers are (briefly) overloaded by queries, perhaps by the 390 attacker. 392 5. Birthday attacks 394 The so called birthday paradox implies that a group of 23 people 395 suffices to have a more than even chance of having two or more 396 members of the group share a birthday. 398 An attacker can benefit from this exact phenomenon if it can force 399 the target resolver to have multiple equivalent (identical QNAME, 400 QTYPE and QCLASS) outstanding queries at any one time to the same 401 authoritative server. 403 Any packet the attacker sends then has a much higher chance of being 404 accepted because it only has to match any of the outstanding queries 405 for that single domain. Compared to the birthday analogy above, of 406 the group composed of queries and responses, the chance of having any 407 of these share an ID rises quickly. 409 As long as small numbers of queries are sent out, the chance of 410 successfully spoofing a response rises linearly with the number of 411 outstanding queries for the exact domain and nameserver. 413 For larger numbers this effect is less pronounced. 415 More details are available in US-CERT [vu-457875]. 417 6. Accepting only in-domain records 419 Responses from authoritative nameservers often contain information 420 that is not part of the zone for which we deem it authoritative. As 421 an example, a query for the MX record of a domain might get as its 422 responses a mail exchanger in another domain, and additionally the IP 423 address of this mail exchanger. 425 If accepted uncritically, the resolver stands the chance of accepting 426 data from an untrusted source. Care must be taken to only accept 427 data if it is known that the originator is authoritative for the 428 QNAME or a parent of the QNAME. 430 One very simple way to achieve this is to only accept data if it is 431 part of the domain the query was for. 433 7. Combined difficulty 435 Given a known or static destination port, matching ID field, source 436 and destination address requires on average in the order of 2 * 2^15 437 = 65000 packets, assuming a zone has 2 authoritative nameservers. 439 If the window of opportunity available is around 100ms, as assumed 440 above, an attacker would need to be able to briefly transmit 650000 441 packets/s to have a 50% chance to get spoofed data accepted on the 442 first attempt. 444 A realistic minimal DNS response consists of around 80 bytes, 445 including IP headers, making the packet rate above correspond to a 446 respectable burst of 416Mb/s. 448 As of mid-2006, this kind of bandwidth was not common but not scarce 449 either, especially among those in a position to control many servers. 451 These numbers change when a window of a full second is assumed, 452 possibly because the arrival of the authentic response can be 453 prevented by overloading the bonafide authoritative hosts with decoy 454 queries. This reduces the needed bandwidth to 42 Mb/s. 456 If in addition the attacker is granted more than a single chance and 457 allowed up to 60 minutes of work on a domain with a time to live of 458 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake 459 data accepted. Once equipped with a longer time, matching condition 460 1 mentioned above is straightforward - any popular domain will have 461 been queried a number of times within this hour, and given the short 462 TTL, this would lead to queries to authoritative nameservers, opening 463 windows of opportunity. 465 7.1. Symbols used in calculation 467 Assume the following symbols are used: 469 I: Number distinct IDs available (maximum 65536) 471 P: Number of ports used (maximum around 64000 as ports under 1024 472 are not always available, but often 1) 474 N: Number of authoritative nameservers for a domain (averages 475 around 2.5) 477 F: Number of 'fake' packets sent by the attacker 478 R: Number of packets sent per second by the attacker 480 W: Window of opportunity, in seconds. Bounded by the response 481 time of the authoritative servers (often 0.1s) 483 D: Average number of identical outstanding queries of a resolver 484 (typically 1, see Section 5) 486 A: Number of attempts, one for each window of opportunity 488 7.2. Calculation 490 The probability of spoofing a resolver is equal to the amount of fake 491 packets that arrive within the window of opportunity, divided by the 492 size of the problem space. 494 When the resolver has 'D' multiple identical outstanding queries, 495 each fake packet has a proportionally higher chance of matching any 496 of these queries. This assumption only holds for small values of 497 'D'. 499 In symbols, if the probability of being spoofed is denoted as P_s: 501 D * F 502 P_s = --------- 503 N * P * I 505 It is more useful to reason not in terms of aggregate packets but to 506 convert to packet rate, which can easily be converted to bandwidth if 507 needed. 509 If the Window of opportunity length is 'W' and the attacker can send 510 'R' packets per second, the number of fake packets 'F' that are 511 candidates to be accepted is: 513 D * R * W 514 F = R * W -> P_s = --------- 515 N * P * I 517 Finally, to calculate the combined chance 'P_cs' of spoofing over a 518 chosen time period 'T', it should be realised that the attacker has a 519 new window of opportunity each time the TTL 'TTL' of the target 520 domain expires. This means that the number of attempts 'A' is equal 521 to 'T / TTL'. 523 To calculate the combined chance of at least one success, the 524 following formula holds: 526 (T / TTL) 527 A ( D * R * W ) 528 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) 529 ( N * P * I ) 531 When common numbers (as listed above) for D, W, N, P and I are 532 inserted, this formula reduces to: 534 (T / TTL) 535 ( R ) 536 P_cs = 1 - ( 1 - ------- ) 537 ( 1638400 ) 539 From this formula it can be seen that, if the nameserver 540 implementation is unchanged, only raising the TTL offers protection. 541 Raising N, the number of authoritative nameservers, is not feasible 542 beyond a small number. 544 For the degenerate case of a zero-second TTL, a window of opportunity 545 opens for each query sent, making the effective TTL equal to 'W' 546 above, the response time of the authoritative server. 548 This last case also holds for spoofing techniques which do not rely 549 on TTL expiry, but use repeated and changing queries. 551 8. Discussion 553 The calculations above indicate the relative ease with which DNS data 554 can be spoofed. For example, using the formula derived earlier on an 555 RRSet with a 3600 second TTL, an attacker sending 7000 fake response 556 packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a 557 record in the first 24 hours, which rises to 50% after a week. 559 For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 560 minutes, 50% after less than 3 hours, 90% after around 9 hours. 562 For some classes of attacks, the effective TTL is near zero, as noted 563 above. 565 Note that the attacks mentioned above can be detected by watchful 566 server operators - an unexpected incoming stream of 4.5mbit/s of 567 packets might be noticed. 569 An important assumption however in these calculations is a known or 570 static destination port of the authentic response. 572 If that port number is unknown and needs to be guessed as well, the 573 problem space expands by a factor of 64000, leading the attacker to 574 need in excess of 285Gb/s to achieve similar success rates. 576 Such bandwidth is not generally available, nor expected to be so in 577 the foreseeable future. 579 Note that some firewalls may need reconfiguring if they are currently 580 setup to only allow outgoing queries from a single DNS source port. 582 8.1. Repetitive spoofing attempts for a single domain name 584 Techniques are available to use an effectively infinite number of 585 queries to achieve a desired spoofing goal. In the math above, this 586 reduces the effective TTL to 0. 588 If such techniques are employed, using the same 7000 packets/s rate 589 mentioned above, and using 1 source port, the spoofing chance rises 590 to 50% within 7 seconds. 592 If 64000 ports are used, as recommended in this document, using the 593 same query rate, the 50% level is reached after around 116 hours. 595 9. Forgery countermeasures 597 9.1. Query matching rules 599 A resolver implementation MUST match responses to all of the 600 following attributes of the query: 602 o Source address against query destination address 604 o Destination address against query source address 606 o Destination port against query source port 608 o Query ID 610 o Query name 612 o Query class and type 614 before applying DNS trustworthiness rules (see [RFC2181], section 615 5.4.1). 617 A mismatch and the response MUST be considered invalid. 619 9.2. Extending the Q-ID space by using ports and addresses 621 Resolver implementations MUST: 623 o Use an unpredictable source port for outgoing queries from the 624 range of available ports (53, or 1024 and above) that is as large 625 as possible and practicable; 627 o Use multiple different source ports simultaneously in case of 628 multiple outstanding queries; 630 o Use an unpredictable query ID for outgoing queries, utilizing the 631 full range available (0-65535) 633 Resolvers that have multiple IP addresses SHOULD use them in an 634 unpredictable manner for outgoing queries. 636 Resolver implementations SHOULD provide means to avoid usage of 637 certain ports. 639 Resolvers SHOULD favour authoritative nameservers with which a trust 640 relation has been established; Stub-resolvers SHOULD be able to use 641 TSIG ([RFC2845]) or IPsec ([RFC4301]) when communicating with their 642 recursive resolver 643 In case a cryptographic verification of response validity is 644 available (TSIG, SIG(0)), resolver implementations MAY waive above 645 rules, and rely on this guarantee instead. 647 Proper unpredictability can be achieved by employing a high quality 648 (pseudo-)random generator, as described in [RFC4086]. 650 9.2.1. Justification and Discussion 652 Since an attacker can force a full DNS resolver to send queries to 653 the attacker's own name servers, any constant or sequential state 654 held by such a resolver can be measured, and it must not be trivially 655 easy to reverse engineer the resolver's internal state in a way that 656 allows low-cost high-accuracy prediction of future state. 658 A full DNS resolver with only one or a small number of upstream- 659 facing endpoints is effectively using constants for IP source address 660 and UDP port number, and these are very predictable by potential 661 attackers, and must therefore be avoided. 663 A full DNS resolver that uses a simple increment to get its next DNS 664 query ID is likewise very predictable and so very spoofable. 666 Finally, weak random number generators have been shown to expose 667 their internal state, such that an attacker who witnesses several 668 sequential "random" values can easily predict the next ones. A 669 crypto-strength random number generator is one whose output cannot be 670 predicted no matter how many successive values are witnessed. 672 9.3. Spoof detection and countermeasure 674 If a resolver detects that an attempt is being made to spoof it, 675 perhaps by discovering that many packets fail the criteria as 676 outlined above, it MAY abandon the UDP query and re-issue it over 677 TCP. TCP, by the nature of its use of sequence numbers, is far more 678 resilient against forgery by third parties. 680 10. Security Considerations 682 This document provides clarification of the DNS specification to 683 decrease the probability that DNS responses can be successfully 684 forged. Recommendations found above should be considered 685 complementary to possible cryptographical enhancements of the domain 686 name system, which protect against a larger class of attacks. 688 This document recommends the use of UDP source port number 689 randomization to extend the effective DNS transaction ID beyond the 690 available 16 bits. 692 A resolver that does not implement the recommendations outlined above 693 can easily be forced to accept spoofed responses, which in turn are 694 passed on to client computers - misdirecting (user) traffic to 695 possibly malicious entities. 697 This document directly impacts the security of the Domain Name 698 System, implementers are urged to follow its recommendations. 700 Most security considerations can be found in Section 4 and Section 5, 701 while proposed countermeasures are described in Section 9. 703 For brevity's sake, in lieu of repeating the security considerations 704 references, the reader is referred to these sections. 706 Nothing in this document specifies specific algorithms for operators 707 to use; it does specify algorithms implementations SHOULD or MUST 708 support. 710 It should be noted that the effects of source port randomization may 711 be dramatically reduced by NAT devices which either serialize or 712 limit in volume the UDP source ports used by the querying resolver. 714 DNS recursive servers sitting behind at NAT or a statefull firewall 715 may consume all available NAT translation entries/ports when 716 operating under high query load. Port randomization will cause 717 translation entries to be consumed faster than with fixed query port 719 . To avoid this NAT boxes and statefull firewalls can/should purge 720 outgoing DNS query translation entries 10-17 seconds after the last 721 outgoing query on that mapping was sent. [RFC4787] compliant devices 722 need to treat UDP messages with port 53 differently than most other 723 UDP protocols. 725 To minimize the potential that port/state exhaustion attacks can be 726 staged from the outside, it is recommended that services which 727 generate number of DNS queries for each connection, should be rate 728 limited. This applies in particular to e-mail servers 730 11. IANA Considerations 732 This document does not make any assignments and has no actions for 733 IANA. 735 12. Acknowledgments 737 Source port randomisation in DNS was first implemented and possibly 738 invented by Dan. J. Bernstein. 740 Although any mistakes remain our own, the authors gratefully 741 acknowledge the help and contributions of: 743 Stephane Bortzmeyer, 745 Alfred Hoenes, 747 Peter Koch, 749 Sean Leach, 751 Norbert Sendetzky, 753 Paul Vixie, 755 Florian Weimer, 757 Wouter Wijngaards, 759 Dan Wing 761 13. References 763 13.1. Normative References 765 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 766 STD 13, RFC 1034, November 1987. 768 [RFC1035] Mockapetris, P., "Domain names - implementation and 769 specification", STD 13, RFC 1035, November 1987. 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 775 Specification", RFC 2181, July 1997. 777 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 778 April 2001. 780 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 781 Defeating Denial of Service Attacks which employ IP Source 782 Address Spoofing", BCP 38, RFC 2827, May 2000. 784 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 785 Wellington, "Secret Key Transaction Authentication for DNS 786 (TSIG)", RFC 2845, May 2000. 788 [RFC3013] Killalea, T., "Recommended Internet Service Provider 789 Security Services and Procedures", BCP 46, RFC 3013, 790 November 2000. 792 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 793 Rose, "DNS Security Introduction and Requirements", 794 RFC 4033, March 2005. 796 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 797 Requirements for Security", BCP 106, RFC 4086, June 2005. 799 13.2. Informative References 801 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 802 and Support", STD 3, RFC 1123, October 1989. 804 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 805 Name System (DNS)", RFC 3833, August 2004. 807 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 808 Internet Protocol", RFC 4301, December 2005. 810 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 811 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 812 RFC 4787, January 2007. 814 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 815 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 816 October 2008. 818 [vu-457875] 819 United States CERT, "Various DNS service implementations 820 generate multiple simultaneous queries for the same 821 resource record", VU 457875, November 2002. 823 Authors' Addresses 825 Bert Hubert 826 Netherlabs Computer Consulting BV. 827 Braillelaan 10 828 Rijswijk (ZH) 2289 CM 829 The Netherlands 831 Email: bert.hubert@netherlabs.nl 833 Remco van Mook 834 Equinix 835 Auke Vleerstraat 1 836 Enschede 7521 PE 837 The Netherlands 839 Email: remco@eu.equinix.com