idnits 2.17.1 draft-ietf-dnsext-forgery-resilience-01.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 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 723. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC1035, 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 RFC1035, updated by this document, for RFC5378 checks: 1987-11-01) -- 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 2007) is 6120 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) ** Downref: Normative reference to an Informational RFC: RFC 3833 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: 1035 (if approved) R. van Mook 5 Intended status: Standards Track Virtu 6 Expires: January 2, 2008 July 2007 8 Measures for making DNS more resilient against forged answers 9 draft-ietf-dnsext-forgery-resilience-01.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 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The current internet climate poses serious threats to the Domain Name 43 System. In the interim period before the DNS protocol can be secured 44 more fully, measures can already be taken to make 'spoofing' a 45 recursing nameserver many orders of magnitude harder. 47 Even a cryptographically secured DNS benefits from having the ability 48 to discard bogus answers quickly, as this potentially saves large 49 amounts of computation. 51 By describing certain behaviour that has previously not been 52 standardised, this document sets out how to make the DNS more 53 resilient against accepting incorrect answers. This document updates 54 RFC1034. 56 Table of Contents 58 1. Requirements and definitions . . . . . . . . . . . . . . . . . 3 59 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6 63 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Matching the question . . . . . . . . . . . . . . . . . . 7 65 4.2. Matching the ID field . . . . . . . . . . . . . . . . . . 8 66 4.3. Matching the source address of the authentic answer . . . 8 67 4.4. Matching the destination address of the authentic 68 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. Have the answer arrive before the authentic answer . . . . 9 70 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11 72 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12 74 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 79 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 81 Intellectual Property and Copyright Statements . . . . . . . . . . 22 83 1. Requirements and definitions 85 1.1. Definitions 87 This document uses the following definitions: 89 Client: typically a 'stub-resolver' on an end-user's computer 91 Resolver: a nameserver performing recursive service for clients, 92 also known as a caching server 94 Question: a question sent out by a resolver, typically in a UDP 95 packet 97 Answer: the answer sent back by an authoritative nameserver, 98 typically in a UDP packet 100 Third party: any host other than the resolver or the intended 101 recipient of a question. The third party may have access to a 102 random authoritative nameserver, but has no access to packets 103 transmitted by the Resolver or authoritative server 105 Attacker: malicious third party. 107 Spoof: the activity of attempting to subvert the DNS process by 108 getting a chosen answer accepted 110 Authentic answer: the answer that would be accepted if no third 111 party interferes 113 Target domain: domain for which the attacker wishes to spoof in an 114 answer 116 Fake data: answer chosen by the attacker 118 TBD: Do we need to talk about stub resolvers? Does this draft apply 119 to them? 121 1.2. Key words 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Introduction 129 This document describes several common problems in DNS 130 implementations which, although previously recognized, remain largely 131 unsolved. Besides briefly recapping these problems, this RFC 132 contains rules that, if implemented, make complying resolvers vastly 133 more resistant to the attacks described. 135 Almost every transaction on the internet involves the Domain Name 136 System, which is described in [RFC1034], [RFC1035] and beyond. 138 Additionally, it has recently become possible to acquire SSL 139 certificates with no other confirmation of identity than the ability 140 to respond to a verification email sent via SMTP ([RFC2821]) - which 141 generally uses DNS for its routing. 143 In other words, any party that (temporarily) controls the Domain Name 144 System is in a position to reroute most kinds of Internet 145 transactions, including the verification steps in acquiring an SSL 146 certificate for a domain. This in turn means that even transactions 147 protected by SSL could be diverted. 149 It is entirely conceivable that such rerouted traffic could be used 150 to the disadvantage of internet users. 152 These and other developments have made the security and 153 trustworthiness of DNS of renewed importance. Although the DNS 154 community is working hard on finalising and implementing a 155 cryptographically enhanced DNS protocol, steps should be taken to 156 make sure that the existing use of DNS is as secure as possible 157 within the bounds of the relevant standards. 159 It should be noted that the most commonly used resolver currently 160 does not perform as well as possible in this respect, making this 161 document of urgent importance. 163 A thorough analysis of risks facing DNS can be found in [RFC3833]. 165 This document expands on some of the risks mentioned in RFC 3833, 166 especially those outlined in the sections on 'ID Guessing and Query 167 Prediction' and 'Name Chaining'. Furthermore, it emphasises a number 168 of existing rules and guidelines embodied in the relevant STDs and 169 RFCs. The following also specifies new requirements to make sure the 170 Domain Name System can be relied upon until a more secure protocol 171 has been standardised and deployed. 173 It should be noted that even when all measures suggested below are 174 implemented, protocol users are not protected against third parties 175 with the ability to intercept, change or inject packets sent to the 176 resolver. 178 For protocol extensions under development that offer protection 179 against these scenarios, see [RFC4033] and beyond. 181 3. Description of DNS spoofing 183 When certain steps are taken it is feasible to 'spoof' the current 184 deployed majority of caching resolvers with carefully crafted and 185 timed DNS packets. Once spoofed, a caching server will repeat the 186 data it wrongfully accepted, and make its clients contact the wrong, 187 and possibly malicious, servers. 189 To understand how this process works it is important to know what 190 makes a resolver (and more specifically a caching server) accept an 191 answer. 193 Section 5.3.3 of [RFC1034] presaged the present problem: 195 The resolver should be highly paranoid in its parsing of responses. 196 It should also check that the response matches the query it sent 197 using the ID field in the response. 199 DNS data is accepted by a resolver if and only if: 201 1. The question section of the reply packet is identical to that of 202 a question packet currently waiting for an answer 204 2. The ID field of the reply packet matches that of the question 205 packet 207 3. The answer comes from the same network address the question was 208 sent to 210 4. The answer comes in on the same network address, including port 211 number, as the question was sent from 213 5. It is the first answer to match the previous four conditions. 215 Note that the fifth condition can strictly speaking be derived from 216 the first. It is included for clarity reasons only. 218 If a third party succeeds in meeting the first four conditions before 219 the answer from the authentic answer does so, it is in a position to 220 feed a resolver fabricated data. When it does so, we dub it an 221 attacker, attempting to spoof in fake data. 223 All conditions mentioned above can theoretically be met, with the 224 difficulty being a function of the resolver implementation and zone 225 configuration. 227 4. Details 229 The previous paragraph discussed a number of requirements an attacker 230 must match in order to spoof in manipulated (or fake) data. This 231 section discusses the relative difficulties and how implementation 232 defined choices impact the amount of work an attacker has to perform 233 to meet said difficulties. 235 Some more details can be found in section 2.2 of [RFC3833]. 237 4.1. Matching the question 239 Formally, there is no need for a nameserver to perform service except 240 for its operator, its customers or more generally its users. 241 Recently, open recursing nameservers have been used to amplify denial 242 of service attacks. 244 In spite of this, many resolvers perform at least partial service for 245 the whole world. This is partially out of lack of concern, and is 246 reminiscent of the open relay SMTP service the net enjoyed up to the 247 early 1990s. Some access providers may serve so many subnets that it 248 is hard to enumerate these all in the DNS configuration. 250 Providing full service enables the third party to send the target 251 resolver a question for the domain name it intends to spoof. On 252 receiving this question, and not finding the answer in its cache, the 253 resolver will transmit questions to relevant authoritative 254 nameservers. This opens up a window of opportunity for getting fake 255 answer data accepted. 257 Some operators restrict access by not recursing for unauthorised IP 258 addresses, but only respond with data from the cache. This makes 259 spoofing harder for a third party as it cannot then force the exact 260 moment a question will be asked. It is still possible however to 261 determine a time range when this will happen, because nameservers 262 helpfully publish the decreasing TTL of entries in the cache, which 263 indicate from which absolute time onwards a new query could be sent 264 to refresh the expired entry. 266 The time to live of the 'target domain' determines how often a window 267 of opportunity is available, which implies that a short TTL makes 268 spoofing far more viable. 270 Note that the attacker might very well have authorised access to the 271 target resolver by virtue of being a customer or employee of its 272 operator. 274 4.2. Matching the ID field 276 The DNS ID field is 16 bits wide, meaning that if full use is made of 277 all these bits, and if their contents are truly random, it will 278 require on average 32768 attempts to guess. Anecdotal evidence 279 suggests there are implementations utilising only 14 bits, meaning on 280 average 8192 attempts will suffice. 282 Additionally, if the target nameserver can be forced into having 283 multiple identical questions outstanding, the 'Birthday Attack' 284 phenomenon means that any fake data sent by the attacker is matched 285 against multiple outstanding questions, significantly raising the 286 chance of success. Further details in Section 5. 288 4.3. Matching the source address of the authentic answer 290 Most domains have two or three authoritative nameservers, which make 291 matching the source address of the authentic answer very likely with 292 even a naive choice having a double digit success rate. 294 Most recursing nameservers store relative performance indications of 295 authoritative nameservers, which may make it easier to predict which 296 nameserver would originally be queried - the one most likely to 297 respond the quickest. 299 Generally, this condition requires at most two or three attempts 300 before it is matched. 302 It should be noted that meeting this condition entails being able to 303 transmit packets on behalf of the address of the authoritative 304 nameserver. While several important documents ([RFC2827] and 305 [RFC3013] specifically) direct internet access providers to prevent 306 their customers from assuming IP addresses that are not assigned to 307 them, these recommendations are not universally (nor even widely) 308 implemented. 310 4.4. Matching the destination address of the authentic answer 312 Note that the destination address of the authentic answer is the 313 source address of the original question. 315 The actual address of a recursing nameserver is generally known; the 316 port used for asking questions is harder to determine. Most current 317 resolvers pick a random port at startup and use this for all outgoing 318 questions. In quite a number of cases the source port of outgoing 319 questions is fixed at the traditional DNS assigned port of 53. 321 If the source port of the original question is random, but static, 322 any authoritative nameserver under observation by the attacker can be 323 used to determine this port. This means that matching this 324 conditions often requires no guess work. 326 If multiple ports are used for sending questions, this enlarges the 327 effective address space by a factor equal to the number of ports 328 used. 330 Less common resolving servers choose a random port per outgoing 331 question. If this strategy is followed, this port number can be 332 regarded as an additional ID field, again containing up to 16 bits. 334 If the maximum ports range is utilized, on average, around 32128 335 source ports would have to be tried before matching the source port 336 of the original question as ports below 1024 may be unavailable for 337 use, leaving 64512 options. 339 It should be noted that a firewall will not prevent the matching of 340 this address, as it will accept answers that (appear) to come from 341 the correct address, offering no additional security. 343 4.5. Have the answer arrive before the authentic answer 345 Once any packet has matched the previous four conditions, no further 346 answers should be accepted. 348 This means that the third party has a limited time in which to inject 349 its spoofed answer, typically in the order of at most 100ms. 351 This time period can be far longer if the authentic authoritative 352 nameservers are (briefly) overloaded by queries, perhaps by the 353 attacker. 355 5. Birthday attacks 357 A curious mathematical phenomenon means that a group of 22 people 358 suffices to have a more than even chance at having two or more 359 members of the group share a birthday. 361 An attacker can benefit from this phenomenon if it can force the 362 target resolver to have multiple outstanding questions at any one 363 time for the same domain to the same authoritative server. 365 Any packet the attacker sends then has a much higher chance of being 366 accepted because it only has to match any of the outstanding queries 367 for that single domain. Compared to the birthday analogy above, of 368 the group composed of questions and answers, the chance of having any 369 of these share an ID rises quickly. 371 As long as small numbers of questions are sent out, the chance of 372 successfully spoofing an anwers rises linearly with the number of 373 outstanding questions for the exact domain and nameserver. 375 For larger numbers this effect is less pronounced. 377 More details are available in US-CERT [vu-457875]. 379 6. Accepting only in-zone answers 381 Answers from authoritative nameservers often contain information that 382 is not part of the zone for which we deem it authoritative. As an 383 example, a query for the MX record of a domain might get as its 384 answer a mail exchanger in another domain, and additionally the IP 385 address of this mail exchanger. 387 If accepted uncritically, the resolver stands the chance of accepting 388 data from an untrusted source. Care must be taken to only accept 389 data if it is known that the originator is authoritative for that 390 data. 392 One very simple way to achieve this is to only accept data if it is 393 part of the domain we asked the question for. 395 7. Combined difficulty 397 Given a known or static destination port, matching ID field, source 398 and destination address requires on average in the order of 2 * 2^15 399 = 65000 packets, assuming a domain has 2 authoritative nameservers. 401 If the window of opportunity available is around 100ms, as assumed 402 above, an attacker would need to be able to briefly transmit 650000 403 packets/s to have a 50% chance to get spoofed data accepted on the 404 first attempt. 406 A realistic minimal DNS answer consists of around 80 bytes, including 407 IP headers, making the packet rate above correspond to a respectable 408 burst of 416Mb/s. 410 As of mid-2006, this kind of bandwidth was not common but not scarce 411 either, especially among those in a position to control many servers. 413 These numbers change when a window of a full second is assumed, 414 possibly because the arrival of the authentic answer can be prevented 415 by overloading the bonafide authoritative hosts with decoy questions. 416 This reduces the needed bandwith to 42 Mb/s. 418 If in addition the attacker is granted more than a single chance and 419 allowed up to 60 minutes of work on a domain with a time to live of 420 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake 421 data accepted. Once equipped with a longer time, matching condition 422 1 mentioned above is straightforward - any popular domain will have 423 been queried a number of times within this hour, and given the short 424 TTL, this would lead to questions to authoritative nameservers, 425 opening windows of opportunity. 427 7.1. Symbols used in calculation 429 Assume the following symbols are used: 431 I: Number distinct IDs available (maximum 65536) 433 P: Number of ports used (maximum around 64000 as ports under 1024 434 are not always available, but often 1) 436 N: Number of authoritative nameservers for a domain (averages 437 around 2.5) 439 F: Number of 'fake' packets sent by the attacker 440 R: Number of packets sent per second by the attacker 442 W: Window of opportunity, in seconds. Bounded by the response 443 time of the authoritative servers (often 0.1s) 445 D: Average number of identical outstanding questions of a resolver 446 (typically 1, see Section 5) 448 A: Number of attempts, one for each window of opportunity 450 7.2. Calculation 452 The probability of spoofing a resolver is equal to amount of fake 453 packets that arrive within the window of opportunity, divided by the 454 size of the problem space. 456 When the resolver has 'D' multiple identical outstanding questions, 457 each fake packet has a proportionally higher chance of matching any 458 of these questions. This assumption only holds for small values of 459 'D'. 461 In symbols, if the probability of being spoofed is denoted as P_s: 463 D * F 464 P_s = --------- 465 N * P * I 467 It is more useful to reason not in terms of aggregate packets but to 468 convert to packet rate, which can easily be converted to bandwidth if 469 needed. 471 If the Window of opportunity length is 'W' and the attacker can send 472 'R' packets per second, the number of fake packets 'F' that are 473 candidates to be accepted is: 475 D * R * W 476 F = R * W -> P_s = ---------- 477 N * P * I 479 Finally, to calculate the combined chance 'P_cs' of spoofing over a 480 chosen time period 'T', it should be realised that the attacker has a 481 new window of opportunity each time the TTL 'TTL' of the target 482 domain expires. This means that the number of attempts 'A' is equal 483 to 'T / TTL'. 485 To calculate the combined chance of at least one success, the 486 following formula holds: 488 (T / TTL) 489 A ( D * R * W ) 490 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) 491 ( N * P * I ) 493 When common numbers (as listed above) for D, W, N, P and I are 494 inserted, this formula reduces to: 496 (T / TTL) 497 ( R ) 498 P_cs = 1 - ( 1 - ------- ) 499 ( 1638400 ) 501 From this formula it can be seen that, if the nameserver 502 implementation is unchanged, only raising the TTL offers protection. 503 Raising N, the number of authoritative nameservers, is not feasible 504 beyond a small number. 506 For the degenerate case of a zero-second TTL, a window of opportunity 507 opens for each question asked, making the effective TTL equal to 'W' 508 above, the response time of the authoritative server. 510 8. Discussion 512 The calculations above indicate the relative ease with which DNS data 513 can be spoofed. For example, using the formula derived earlier on a 514 domain with a 3600 second TTL, an attacker sending 7000 fake answer 515 packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a 516 record in the first 24 hours, which rises to 50% after a week. 518 For a domain with a TTL of 60 seconds, the 10% level is hit after 24 519 minutes, 50% after less than 3 hours, 90% after around 9 hours. 521 Note that the attacks mentioned above can be detected by watchful 522 server operators - an unexpected incoming stream of 4.5mbit/s of 523 packets might be noticed. 525 An important assumption however in these calculations is a known or 526 static destination port of the authentic answer. 528 If that port number is unknown and needs to be guessed as well, the 529 problem space expands by a factor of 64000, leading the attacker to 530 need in excess of 285Gb/s to achieve similar success rates. 532 Such bandwidth is not generally available, nor expected to be so in 533 the foreseeable future. 535 Note that some firewalls may need reconfiguring if they are currently 536 setup to only allow outgoing queries from a single DNS source port. 538 9. Countermeasures 540 NOTE: This section is expected to change, and is very much open to 541 discussion! 543 Implementations MUST be able to send queries from ANY UDP port 544 available to it. 546 Implementations SHOULD use good random source to select a Query ID 547 for next query 549 Implementations SHOULD NOT use UDP source ports <1024 for sending 550 queries 552 Implementations MUST use an as large as possible pool of UDP source 553 ports for sending queries 555 Implementations SHOULD be configurable to use one or multiple ports 556 for queries. 558 Implementations MAY be configurable to use one or more addresses for 559 queries 561 Implementations MUST suppress multiple simultaneous identical queries 562 to the SAME server. 564 Implementations MUST match answers to the following 566 o Remote address 568 o Local address 570 o Query port 572 o Query ID 574 o Question 576 before applying DNS credibility rules. 578 The document can not require the use of either multiple ports or 579 addresses as that is an operational issue and should be addressed in 580 a separate document in DNSOP. 582 NOTE! A previous version of requirements is listed below as an 583 inspiration to further discussions: 585 Given the above, a resolver MAY/SHOULD/MUST: 587 o Use an unpredictable source port for outgoing queries from a range 588 (53, or > 1024) of ports that is as large as possible 590 o Make use of all 16 bits of the ID field 592 o Assure that its choices of port and ID cannot be predicted by an 593 attacker having knowledge of its (pseudo-)random generator 595 o Not have multiple equivalent questions outstanding to any 596 authoritative server, unless all with identical ID and source port 598 A resolver SHOULD offer diagnostics that enable the operator to 599 determine a spoofing attempt is under way. 601 Operators SHOULD attempt to restrict recursing service, either full 602 or partial, to authorised users. 604 A resolver MAY use heuristics to detect an excess of unacceptable 605 answers and take measures if it believes an attempt is made to spoof 606 it. 608 Futhermore, zone operators are urged not to configure the Time To 609 Live of domains to be lower than realistically needed for proper 610 operations. 612 10. Security Considerations 614 This document directly impacts the operational security of the Domain 615 Name System, readers are urged to implement its recommendations. 617 TBD! 619 11. Acknowledgements 621 Source port randomisation in DNS was first implemented and possibly 622 invented by Dan. J. Bernstein. 624 Although any mistakes remain our own, the authors gratefully 625 acknowledge the help and contributions of: 627 Stephane Bortzmeyer, 629 Sean Leach, 631 Norbert Sendetzky 633 12. Normative References 635 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 636 STD 13, RFC 1034, November 1987. 638 [RFC1035] Mockapetris, P., "Domain names - implementation and 639 specification", STD 13, RFC 1035, November 1987. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 645 April 2001. 647 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 648 Defeating Denial of Service Attacks which employ IP Source 649 Address Spoofing", BCP 38, RFC 2827, May 2000. 651 [RFC3013] Killalea, T., "Recommended Internet Service Provider 652 Security Services and Procedures", BCP 46, RFC 3013, 653 November 2000. 655 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 656 Name System (DNS)", RFC 3833, August 2004. 658 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 659 Rose, "DNS Security Introduction and Requirements", 660 RFC 4033, March 2005. 662 [vu-457875] 663 United States CERT, "Various DNS service implementations 664 generate multiple simultaneous queries for the same 665 resource record", VU 457875, November 2002. 667 Authors' Addresses 669 bert hubert 670 Netherlabs Computer Consulting BV. 671 Braillelaan 10 672 Rijswijk (ZH) 2289 CM 673 The Netherlands 675 Email: bert.hubert@netherlabs.nl 677 Remco van Mook 678 Virtu 679 Auke Vleerstraat 1 680 Enschede 7521 PE 681 The Netherlands 683 Email: remco@virtu.nl 685 Full Copyright Statement 687 Copyright (C) The IETF Trust (2007). 689 This document is subject to the rights, licenses and restrictions 690 contained in BCP 78, and except as set forth therein, the authors 691 retain all their rights. 693 This document and the information contained herein are provided on an 694 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 695 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 696 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 697 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 698 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 699 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 Intellectual Property 703 The IETF takes no position regarding the validity or scope of any 704 Intellectual Property Rights or other rights that might be claimed to 705 pertain to the implementation or use of the technology described in 706 this document or the extent to which any license under such rights 707 might or might not be available; nor does it represent that it has 708 made any independent effort to identify any such rights. Information 709 on the procedures with respect to rights in RFC documents can be 710 found in BCP 78 and BCP 79. 712 Copies of IPR disclosures made to the IETF Secretariat and any 713 assurances of licenses to be made available, or the result of an 714 attempt made to obtain a general license or permission for the use of 715 such proprietary rights by implementers or users of this 716 specification can be obtained from the IETF on-line IPR repository at 717 http://www.ietf.org/ipr. 719 The IETF invites any interested party to bring to its attention any 720 copyrights, patents or patent applications, or other proprietary 721 rights that may cover technology that may be required to implement 722 this standard. Please address the information to the IETF at 723 ietf-ipr@ietf.org. 725 Acknowledgment 727 Funding for the RFC Editor function is provided by the IETF 728 Administrative Support Activity (IASA).