idnits 2.17.1 draft-ietf-dnsext-forgery-resilience-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 826. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2181, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC1034, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 30, 2008) is 5742 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) ** Downref: Normative reference to an Informational RFC: RFC 3833 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-reflectors-are-evil-05 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: January 31, 2009 July 30, 2008 8 Measures for making DNS more resilient against forged answers 9 draft-ietf-dnsext-forgery-resilience-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 31, 2009. 36 Abstract 38 The current Internet climate poses serious threats to the Domain Name 39 System. In the interim period before the DNS protocol can be secured 40 more fully, measures can already be taken to harden the DNS to make 41 'spoofing' a recursing nameserver many orders of magnitude harder. 43 Even a cryptographically secured DNS benefits from having the ability 44 to discard bogus responses quickly, as this potentially saves large 45 amounts of computation. 47 By describing certain behaviour that has previously not been 48 standardised, this document sets out how to make the DNS more 49 resilient against accepting incorrect responses. This document 50 updates RFC 1034. 52 Table of Contents 54 1. Requirements and definitions . . . . . . . . . . . . . . . . . 4 55 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7 59 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8 60 4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. Matching the question section . . . . . . . . . . . . . . 9 62 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 9 63 4.4. Matching the source address of the authentic response . . 9 64 4.5. Matching the destination address and port of the 65 authentic response . . . . . . . . . . . . . . . . . . . . 9 66 4.6. Have the response arrive before the authentic response . . 10 67 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. Accepting only in-domain records . . . . . . . . . . . . . . . 12 69 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 13 71 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 17 74 9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 17 75 9.2. Extending the Q-ID space by using ports and addresses . . 17 76 9.2.1. Justification and Discussion . . . . . . . . . . . . . 18 77 9.3. Spoof detection and countermeasure . . . . . . . . . . . . 18 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 83 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 85 Intellectual Property and Copyright Statements . . . . . . . . . . 25 87 1. Requirements and definitions 89 1.1. Definitions 91 This document uses the following definitions: 93 Client: typically a 'stub-resolver' on an end-user's computer 95 Resolver: a nameserver performing recursive service for clients, 96 also known as a caching server, or a full service resolver 97 ([RFC1123], paragraph 6.1.3.1) 99 Stub resolver: a very limited Resolver on a client computer, that 100 leaves the recursing work to a full resolver 102 Query: a question sent out by a resolver, typically in a UDP 103 packet 105 Response: the answer sent back by an authoritative nameserver, 106 typically in a UDP packet 108 Third party: any entity other than the resolver or the intended 109 recipient of a question. The third party may have access to an 110 arbitrary authoritative nameserver, but has no access to packets 111 transmitted by the Resolver or authoritative server 113 Attacker: malicious third party. 115 Spoof: the activity of attempting to subvert the DNS process by 116 getting a chosen answer accepted 118 Authentic response: the correct answer that comes from the right 119 authoritative server 121 Target domain name: domain for which the attacker wishes to spoof 122 in an answer 124 Fake data: response chosen by the attacker 126 1.2. Key words 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Introduction 134 This document describes several common problems in DNS 135 implementations which, although previously recognized, remain largely 136 unsolved. Besides briefly recapping these problems, this document 137 contains rules that, if implemented, make complying resolvers vastly 138 more resistant to the attacks described. The goal is to make the 139 existing DNS as secure as possible within the current protocol 140 boundaries. 142 The words below are aimed at authors of resolvers: it is up to 143 operators to decide which nameserver implementation to use, or which 144 options to enable. Operational constraints may override the security 145 concerns described below. However, implementations are expected to 146 allow an operator to enable functionality described in this document. 148 Almost every transaction on the Internet involves the Domain Name 149 System, which is described in [RFC1034], [RFC1035] and beyond. 151 Additionally, it has recently become possible to acquire SSL/TLS 152 certificates with no other confirmation of identity than the ability 153 to respond to a verification email sent via SMTP ([RFC2821]) - which 154 generally uses DNS for its routing. 156 In other words, any party that (temporarily) controls the Domain Name 157 System is in a position to reroute most kinds of Internet 158 transactions, including the verification steps in acquiring an SSL/ 159 TLS certificate for a domain. This in turn means that even 160 transactions protected by SSL/TLS could be diverted. 162 It is entirely conceivable that such rerouted traffic could be used 163 to the disadvantage of Internet users. 165 These and other developments have made the security and 166 trustworthiness of DNS of renewed importance. Although the DNS 167 community is working hard on finalising and implementing a 168 cryptographically enhanced DNS protocol, steps should be taken to 169 make sure that the existing use of DNS is as secure as possible 170 within the bounds of the relevant standards. 172 It should be noted that the most commonly used resolvers currently do 173 not perform as well as possible in this respect, making this document 174 of urgent importance. 176 A thorough analysis of risks facing DNS can be found in [RFC3833]. 178 This document expands on some of the risks mentioned in RFC 3833, 179 especially those outlined in the sections on 'ID Guessing and Query 180 Prediction' and 'Name Chaining'. Furthermore, it emphasises a number 181 of existing rules and guidelines embodied in the relevant DNS 182 protocol specifications. The following also specifies new 183 requirements to make sure the Domain Name System can be relied upon 184 until a more secure protocol has been standardised and deployed. 186 It should be noted that even when all measures suggested below are 187 implemented, protocol users are not protected against third parties 188 with the ability to observe, modify or inject packets in the traffic 189 of a resolver. 191 For protocol extensions that offer protection against these 192 scenarios, see [RFC4033] and beyond. 194 3. Description of DNS spoofing 196 When certain steps are taken it is feasible to 'spoof' the current 197 deployed majority of resolvers with carefully crafted and timed DNS 198 packets. Once spoofed, a caching server will repeat the data it 199 wrongfully accepted, and make its clients contact the wrong, and 200 possibly malicious, servers. 202 To understand how this process works it is important to know what 203 makes a resolver accept a response. 205 The following sentence in section 5.3.3 of [RFC1034] presaged the 206 present problem: 208 The resolver should be highly paranoid in its parsing of responses. 209 It should also check that the response matches the query it sent 210 using the ID field in the response. 212 DNS data is to be accepted by a resolver if and only if: 214 1. The question section of the reply packet is equivalent to that of 215 a question packet currently waiting for a response 217 2. The ID field of the reply packet matches that of the question 218 packet 220 3. The response comes from the same network address the question was 221 sent to 223 4. The response comes in on the same network address, including port 224 number, as the question was sent from 226 In general, the first response matching these four conditions is 227 accepted. 229 If a third party succeeds in meeting the four conditions before the 230 response from the authentic nameserver does so, it is in a position 231 to feed a resolver fabricated data. When it does so, we dub it an 232 attacker, attempting to spoof in fake data. 234 All conditions mentioned above can theoretically be met by a third 235 party, with the difficulty being a function of the resolver 236 implementation and zone configuration. 238 4. Detailed Description of Spoofing Scenarios 240 The previous paragraph discussed a number of requirements an attacker 241 must match in order to spoof in manipulated (or fake) data. This 242 section discusses the relative difficulties and how implementation 243 defined choices impact the amount of work an attacker has to perform 244 to meet said difficulties. 246 Some more details can be found in section 2.2 of [RFC3833]. 248 4.1. Forcing a query 250 Formally, there is no need for a nameserver to perform service except 251 for its operator, its customers or more generally its users. 252 Recently, open recursing nameservers have been used to amplify denial 253 of service attacks. 255 Providing full service enables the third party to send the target 256 resolver a query for the domain name it intends to spoof. On 257 receiving this query, and not finding the answer in its cache, the 258 resolver will transmit queries to relevant authoritative nameservers. 259 This opens up a window of opportunity for getting fake answer data 260 accepted. 262 Queries may however be forced indirectly, for example by inducing a 263 mail server to perform DNS lookups. 265 Some operators restrict access by not recursing for unauthorised IP 266 addresses, but only respond with data from the cache. This makes 267 spoofing harder for a third party as it cannot then force the exact 268 moment a question will be asked. It is still possible however to 269 determine a time range when this will happen, because nameservers 270 helpfully publish the decreasing TTL of entries in the cache, which 271 indicate from which absolute time onwards a new query could be sent 272 to refresh the expired entry. 274 The time to live of the target domain name's RRSets determines how 275 often a window of opportunity is available, which implies that a 276 short TTL makes spoofing far more viable. 278 Note that the attacker might very well have authorised access to the 279 target resolver by virtue of being a customer or employee of its 280 operator. In addition, access may be enabled through the use of 281 reflectors as outlined in [I-D.ietf-dnsop-reflectors-are-evil]. 283 4.2. Matching the question section 285 DNS packets, both queries and responses, contain a question section. 286 Incoming responses should be verified to have a question section that 287 is equivalent to that of the outgoing query. 289 4.3. Matching the ID field 291 The DNS ID field is 16 bits wide, meaning that if full use is made of 292 all these bits, and if their contents are truly random, it will 293 require on average 32768 attempts to guess. Anecdotal evidence 294 suggests there are implementations utilising only 14 bits, meaning on 295 average 8192 attempts will suffice. 297 Additionally, if the target nameserver can be forced into having 298 multiple identical queries outstanding, the 'Birthday Attack' 299 phenomenon means that any fake data sent by the attacker is matched 300 against multiple outstanding queries, significantly raising the 301 chance of success. Further details in Section 5. 303 4.4. Matching the source address of the authentic response 305 It should be noted that meeting this condition entails being able to 306 transmit packets on behalf of the address of the authoritative 307 nameserver. While two Best Current Practice documents ([RFC2827] and 308 [RFC3013] specifically) direct Internet access providers to prevent 309 their customers from assuming IP addresses that are not assigned to 310 them, these recommendations are not universally (nor even widely) 311 implemented. 313 Many zones have two or three authoritative nameservers, which make 314 matching the source address of the authentic response very likely 315 with even a naive choice having a double digit success rate. 317 Most recursing nameservers store relative performance indications of 318 authoritative nameservers, which may make it easier to predict which 319 nameserver would originally be queried - the one most likely to 320 respond the quickest. 322 Generally, this condition requires at most two or three attempts 323 before it is matched. 325 4.5. Matching the destination address and port of the authentic 326 response 328 Note that the destination address of the authentic response is the 329 source address of the original query. 331 The actual address of a recursing nameserver is generally known; the 332 port used for asking questions is harder to determine. Most current 333 resolvers pick an arbitrary port at startup (possibly at random) and 334 use this for all outgoing queries. In quite a number of cases the 335 source port of outgoing questions is fixed at the traditional DNS 336 assigned server port number of 53. 338 If the source port of the original query is random, but static, any 339 authoritative nameserver under observation by the attacker can be 340 used to determine this port. This means that matching this 341 conditions often requires no guess work. 343 If multiple ports are used for sending queries, this enlarges the 344 effective ID space by a factor equal to the number of ports used. 346 Less common resolving servers choose a random port per outgoing 347 query. If this strategy is followed, this port number can be 348 regarded as an additional ID field, again containing up to 16 bits. 350 If the maximum ports range is utilized, on average, around 32256 351 source ports would have to be tried before matching the source port 352 of the original query as ports below 1024 may be unavailable for use, 353 leaving 64512 options. 355 It should be noted that a firewall will not prevent the matching of 356 this address, as it will accept answers that (appear) to come from 357 the correct address, offering no additional security. 359 4.6. Have the response arrive before the authentic response 361 Once any packet has matched the previous four conditions (plus 362 possible additional conditions), no further responses are generally 363 accepted. 365 This means that the third party has a limited time in which to inject 366 its spoofed response. For calculations we will assume a window in 367 order of at most 100ms (depending on the network distance to the 368 authentic authoritative nameserver). 370 This time period can be far longer if the authentic authoritative 371 nameservers are (briefly) overloaded by queries, perhaps by the 372 attacker. 374 5. Birthday attacks 376 The so called birthday paradox implies that a group of 23 people 377 suffices to have a more than even chance of having two or more 378 members of the group share a birthday. 380 An attacker can benefit from this exact phenomenon if it can force 381 the target resolver to have multiple equivalent (identical QNAME, 382 QTYPE and QCLASS) outstanding queries at any one time to the same 383 authoritative server. 385 Any packet the attacker sends then has a much higher chance of being 386 accepted because it only has to match any of the outstanding queries 387 for that single domain. Compared to the birthday analogy above, of 388 the group composed of queries and responses, the chance of having any 389 of these share an ID rises quickly. 391 As long as small numbers of queries are sent out, the chance of 392 successfully spoofing a response rises linearly with the number of 393 outstanding queries for the exact domain and nameserver. 395 For larger numbers this effect is less pronounced. 397 More details are available in US-CERT [vu-457875]. 399 6. Accepting only in-domain records 401 Responses from authoritative nameservers often contain information 402 that is not part of the zone for which we deem it authoritative. As 403 an example, a query for the MX record of a domain might get as its 404 responses a mail exchanger in another domain, and additionally the IP 405 address of this mail exchanger. 407 If accepted uncritically, the resolver stands the chance of accepting 408 data from an untrusted source. Care must be taken to only accept 409 data if it is known that the originator is authoritative for the 410 QNAME or a parent of the QNAME. 412 One very simple way to achieve this is to only accept data if it is 413 part of the domain the query was for. 415 7. Combined difficulty 417 Given a known or static destination port, matching ID field, source 418 and destination address requires on average in the order of 2 * 2^15 419 = 65000 packets, assuming a zone has 2 authoritative nameservers. 421 If the window of opportunity available is around 100ms, as assumed 422 above, an attacker would need to be able to briefly transmit 650000 423 packets/s to have a 50% chance to get spoofed data accepted on the 424 first attempt. 426 A realistic minimal DNS response consists of around 80 bytes, 427 including IP headers, making the packet rate above correspond to a 428 respectable burst of 416Mb/s. 430 As of mid-2006, this kind of bandwidth was not common but not scarce 431 either, especially among those in a position to control many servers. 433 These numbers change when a window of a full second is assumed, 434 possibly because the arrival of the authentic response can be 435 prevented by overloading the bonafide authoritative hosts with decoy 436 queries. This reduces the needed bandwidth to 42 Mb/s. 438 If in addition the attacker is granted more than a single chance and 439 allowed up to 60 minutes of work on a domain with a time to live of 440 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake 441 data accepted. Once equipped with a longer time, matching condition 442 1 mentioned above is straightforward - any popular domain will have 443 been queried a number of times within this hour, and given the short 444 TTL, this would lead to queries to authoritative nameservers, opening 445 windows of opportunity. 447 7.1. Symbols used in calculation 449 Assume the following symbols are used: 451 I: Number distinct IDs available (maximum 65536) 453 P: Number of ports used (maximum around 64000 as ports under 1024 454 are not always available, but often 1) 456 N: Number of authoritative nameservers for a domain (averages 457 around 2.5) 459 F: Number of 'fake' packets sent by the attacker 460 R: Number of packets sent per second by the attacker 462 W: Window of opportunity, in seconds. Bounded by the response 463 time of the authoritative servers (often 0.1s) 465 D: Average number of identical outstanding queries of a resolver 466 (typically 1, see Section 5) 468 A: Number of attempts, one for each window of opportunity 470 7.2. Calculation 472 The probability of spoofing a resolver is equal to the amount of fake 473 packets that arrive within the window of opportunity, divided by the 474 size of the problem space. 476 When the resolver has 'D' multiple identical outstanding queries, 477 each fake packet has a proportionally higher chance of matching any 478 of these queries. This assumption only holds for small values of 479 'D'. 481 In symbols, if the probability of being spoofed is denoted as P_s: 483 D * F 484 P_s = --------- 485 N * P * I 487 It is more useful to reason not in terms of aggregate packets but to 488 convert to packet rate, which can easily be converted to bandwidth if 489 needed. 491 If the Window of opportunity length is 'W' and the attacker can send 492 'R' packets per second, the number of fake packets 'F' that are 493 candidates to be accepted is: 495 D * R * W 496 F = R * W -> P_s = --------- 497 N * P * I 499 Finally, to calculate the combined chance 'P_cs' of spoofing over a 500 chosen time period 'T', it should be realised that the attacker has a 501 new window of opportunity each time the TTL 'TTL' of the target 502 domain expires. This means that the number of attempts 'A' is equal 503 to 'T / TTL'. 505 To calculate the combined chance of at least one success, the 506 following formula holds: 508 (T / TTL) 509 A ( D * R * W ) 510 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) 511 ( N * P * I ) 513 When common numbers (as listed above) for D, W, N, P and I are 514 inserted, this formula reduces to: 516 (T / TTL) 517 ( R ) 518 P_cs = 1 - ( 1 - ------- ) 519 ( 1638400 ) 521 From this formula it can be seen that, if the nameserver 522 implementation is unchanged, only raising the TTL offers protection. 523 Raising N, the number of authoritative nameservers, is not feasible 524 beyond a small number. 526 For the degenerate case of a zero-second TTL, a window of opportunity 527 opens for each query sent, making the effective TTL equal to 'W' 528 above, the response time of the authoritative server. 530 8. Discussion 532 The calculations above indicate the relative ease with which DNS data 533 can be spoofed. For example, using the formula derived earlier on an 534 RRSet with a 3600 second TTL, an attacker sending 7000 fake response 535 packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a 536 record in the first 24 hours, which rises to 50% after a week. 538 For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 539 minutes, 50% after less than 3 hours, 90% after around 9 hours. 541 Note that the attacks mentioned above can be detected by watchful 542 server operators - an unexpected incoming stream of 4.5mbit/s of 543 packets might be noticed. 545 An important assumption however in these calculations is a known or 546 static destination port of the authentic response. 548 If that port number is unknown and needs to be guessed as well, the 549 problem space expands by a factor of 64000, leading the attacker to 550 need in excess of 285Gb/s to achieve similar success rates. 552 Such bandwidth is not generally available, nor expected to be so in 553 the foreseeable future. 555 Note that some firewalls may need reconfiguring if they are currently 556 setup to only allow outgoing queries from a single DNS source port. 558 9. Forgery countermeasures 560 9.1. Query matching rules 562 A resolver implementation MUST match responses to all of the 563 following attributes of the query: 565 o Source address against query destination address 567 o Destination address against query source address 569 o Destination port against query source port 571 o Query ID 573 o Query name 575 o Query class and type 577 before applying DNS trustworthiness rules (see [RFC2181], section 578 5.4.1). 580 A mismatch and the response MUST be considered invalid. 582 9.2. Extending the Q-ID space by using ports and addresses 584 Resolver implementations MUST: 586 o Use an unpredictable source port for outgoing queries from the 587 range of available ports (53, or 1024 and above) that is as large 588 as possible and practicable; 590 o Use multiple different source ports simultaneously in case of 591 multiple outstanding queries; 593 o Use an unpredictable query ID for outgoing queries, utilizing the 594 full range available (0-65535) 596 Resolvers that have multiple IP addresses SHOULD use them in an 597 unpredictable manner for outgoing queries. 599 Resolvers SHOULD favour authoritative nameservers with which a trust 600 relation has been established; Stub-resolvers SHOULD be able to use 601 TSIG ([RFC2845]) or IPsec ([RFC4301]) when communicating with their 602 recursive resolver 604 In case a cryptographic verification of response validity is 605 available (TSIG, SIG(0)), resolver implementations MAY waive above 606 rules, and rely on this guarantee instead. 608 Proper unpredictability can be achieved by employing a high quality 609 (pseudo-)random generator, as described in [RFC4086]. 611 9.2.1. Justification and Discussion 613 Since an attacker can force a full DNS resolver to send queries to 614 the attacker's own name servers, any constant or sequential state 615 held by such a resolver can be measured, and it must not be trivially 616 easy to reverse engineer the resolver's internal state in a way that 617 allows low-cost high-accuracy prediction of future state. 619 A full DNS resolver with only one or a small number of upstream- 620 facing endpoints is effectively using constants for IP source address 621 and UDP port number, and these are very predictable by potential 622 attackers, and must therefore be avoided. 624 A full DNS resolver that uses a simple increment to get its next DNS 625 ID is likewise very predictable and so very spoofable. 627 Finally, weak random number generators have been shown to expose 628 their internal state, such that an attacker who witnesses several 629 sequential "random" values can easily predict the next ones. A 630 crypto-strength random number generator is one whose output cannot be 631 predicted no matter how many successive values are witnessed. 633 9.3. Spoof detection and countermeasure 635 If a resolver detects that an attempt is being made to spoof it, 636 perhaps by discovering that many packets fail the criteria as 637 outlined above, it MAY abandon the UDP query and re-issue it over 638 TCP. TCP, by the nature of its use of sequence numbers, is far more 639 resilient against forgery by third parties. 641 10. Security Considerations 643 This document provides clarification of the DNS specification to 644 decrease the probability that DNS responses can be successfully 645 forged. Recommendations found above should be considered 646 complementary to possible cryptographical enhancements of the domain 647 name system, which protect against a larger class of attacks. 649 This document recommends the use of UDP source port number 650 randomization to extend the effective DNS transaction ID beyond the 651 available 16 bits. 653 A resolver that does not implement the recommendations outlined above 654 can easily be forced to accept spoofed responses, which in turn are 655 passed on to client computers - misdirecting (user) traffic to 656 possibly malicious entities. 658 This document directly impacts the security of the Domain Name 659 System, implementers are urged to follow its recommendations. 661 Most security considerations can be found in Section 4 and Section 5, 662 while proposed countermeasures are described in Section 9. 664 For brevity's sake, in lieu of repeating the security considerations 665 references, the reader is referred to these sections. 667 Nothing in this document specifies specific algorithms for operators 668 to use; it does specify algorithms implementations SHOULD or MUST 669 support. 671 The above notwithstanding, it should be noted that using a low Time 672 To Live for DNS records raises the chances of an attacker spoofing a 673 resolver. 675 It should be noted that the effects of source port randomization may 676 be dramatically reduced by NAT devices which either serialize or 677 limit in volume the UDP source ports used by the querying resolver." 679 11. IANA Considerations 681 This document does not make any assignments and has no actions for 682 IANA. 684 12. Acknowledgements 686 Source port randomisation in DNS was first implemented and possibly 687 invented by Dan. J. Bernstein. 689 Although any mistakes remain our own, the authors gratefully 690 acknowledge the help and contributions of: 692 Stephane Bortzmeyer, 694 Alfred Hoenes, 696 Peter Koch, 698 Sean Leach, 700 Norbert Sendetzky, 702 Paul Vixie, 704 Florian Weimer, 706 Wouter Wijngaards, 708 Dan Wing 710 13. References 712 13.1. Normative References 714 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 715 STD 13, RFC 1034, November 1987. 717 [RFC1035] Mockapetris, P., "Domain names - implementation and 718 specification", STD 13, RFC 1035, November 1987. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 724 Specification", RFC 2181, July 1997. 726 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 727 April 2001. 729 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 730 Defeating Denial of Service Attacks which employ IP Source 731 Address Spoofing", BCP 38, RFC 2827, May 2000. 733 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 734 Wellington, "Secret Key Transaction Authentication for DNS 735 (TSIG)", RFC 2845, May 2000. 737 [RFC3013] Killalea, T., "Recommended Internet Service Provider 738 Security Services and Procedures", BCP 46, RFC 3013, 739 November 2000. 741 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 742 Name System (DNS)", RFC 3833, August 2004. 744 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 745 Rose, "DNS Security Introduction and Requirements", 746 RFC 4033, March 2005. 748 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 749 Requirements for Security", BCP 106, RFC 4086, June 2005. 751 13.2. Informative References 753 [I-D.ietf-dnsop-reflectors-are-evil] 754 Damas, J. and F. Neves, "Preventing Use of Recursive 755 Nameservers in Reflector Attacks", 756 draft-ietf-dnsop-reflectors-are-evil-05 (work in 757 progress), December 2007. 759 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 760 and Support", STD 3, RFC 1123, October 1989. 762 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 763 Internet Protocol", RFC 4301, December 2005. 765 [vu-457875] 766 United States CERT, "Various DNS service implementations 767 generate multiple simultaneous queries for the same 768 resource record", VU 457875, November 2002. 770 Authors' Addresses 772 Bert Hubert 773 Netherlabs Computer Consulting BV. 774 Braillelaan 10 775 Rijswijk (ZH) 2289 CM 776 The Netherlands 778 Email: bert.hubert@netherlabs.nl 780 Remco van Mook 781 Equinix 782 Auke Vleerstraat 1 783 Enschede 7521 PE 784 The Netherlands 786 Email: remco@eu.equinix.com 788 Full Copyright Statement 790 Copyright (C) The IETF Trust (2008). 792 This document is subject to the rights, licenses and restrictions 793 contained in BCP 78, and except as set forth therein, the authors 794 retain all their rights. 796 This document and the information contained herein are provided on an 797 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 798 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 799 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 800 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 801 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 802 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 804 Intellectual Property 806 The IETF takes no position regarding the validity or scope of any 807 Intellectual Property Rights or other rights that might be claimed to 808 pertain to the implementation or use of the technology described in 809 this document or the extent to which any license under such rights 810 might or might not be available; nor does it represent that it has 811 made any independent effort to identify any such rights. Information 812 on the procedures with respect to rights in RFC documents can be 813 found in BCP 78 and BCP 79. 815 Copies of IPR disclosures made to the IETF Secretariat and any 816 assurances of licenses to be made available, or the result of an 817 attempt made to obtain a general license or permission for the use of 818 such proprietary rights by implementers or users of this 819 specification can be obtained from the IETF on-line IPR repository at 820 http://www.ietf.org/ipr. 822 The IETF invites any interested party to bring to its attention any 823 copyrights, patents or patent applications, or other proprietary 824 rights that may cover technology that may be required to implement 825 this standard. Please address the information to the IETF at 826 ietf-ipr@ietf.org.