7Network Working Group A. Hubert
8Request for Comments: 5452 Netherlabs Computer Consulting BV.
9Updates: 2181 R. van Mook
10Category: Standards Track Equinix
14 Measures for Making DNS More Resilient against Forged Answers
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (c) 2009 IETF Trust and the persons identified as the
27 document authors. All rights reserved.
29 This document is subject to BCP 78 and the IETF Trust's Legal
30 Provisions Relating to IETF Documents (http://trustee.ietf.org/
31 license-info) in effect on the date of publication of this document.
32 Please review these documents carefully, as they describe your rights
33 and restrictions with respect to this document.
37 The current Internet climate poses serious threats to the Domain Name
38 System. In the interim period before the DNS protocol can be secured
39 more fully, measures can already be taken to harden the DNS to make
40 'spoofing' a recursing nameserver many orders of magnitude harder.
42 Even a cryptographically secured DNS benefits from having the ability
43 to discard bogus responses quickly, as this potentially saves large
44 amounts of computation.
46 By describing certain behavior that has previously not been
47 standardized, this document sets out how to make the DNS more
48 resilient against accepting incorrect responses. This document
58Hubert & van Mook Standards Track [Page 1]
60RFC 5452 DNS Resilience against Forged Answers January 2009
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4
67 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
68 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5
69 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5
70 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6
71 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6
72 4.2. Matching the Question Section . . . . . . . . . . . . . . 7
73 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7
74 4.4. Matching the Source Address of the Authentic Response . . 7
75 4.5. Matching the Destination Address and Port of the
76 Authentic Response . . . . . . . . . . . . . . . . . . . . 8
77 4.6. Have the Response Arrive before the Authentic Response . . 8
78 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9
79 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9
80 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10
81 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10
82 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11
83 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13
85 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13
86 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
87 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14
88 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14
89 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15
90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
94 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
114Hubert & van Mook Standards Track [Page 2]
116RFC 5452 DNS Resilience against Forged Answers January 2009
121 This document describes several common problems in DNS
122 implementations, which, although previously recognized, remain
123 largely unsolved. Besides briefly recapping these problems, this
124 document contains rules that, if implemented, make complying
125 resolvers vastly more resistant to the attacks described. The goal
126 is to make the existing DNS as secure as possible within the current
129 The words below are aimed at authors of resolvers: it is up to
130 operators to decide which nameserver implementation to use, or which
131 options to enable. Operational constraints may override the security
132 concerns described below. However, implementations are expected to
133 allow an operator to enable functionality described in this document.
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 Secure
139 Socket Layer/Transport Layer Security (SSL/TLS) certificates with no
140 other confirmation of identity than the ability to respond to a
141 verification email sent via SMTP ([RFC5321]) -- which generally uses
144 In other words, any party that (temporarily) controls the Domain Name
145 System is in a position to reroute most kinds of Internet
146 transactions, including the verification steps in acquiring an SSL/
147 TLS certificate for a domain. This in turn means that even
148 transactions protected by SSL/TLS could be diverted.
150 It is entirely conceivable that such rerouted traffic could be used
151 to the disadvantage of Internet users.
153 These and other developments have made the security and
154 trustworthiness of DNS of renewed importance. Although the DNS
155 community is working hard on finalizing and implementing a
156 cryptographically enhanced DNS protocol, steps should be taken to
157 make sure that the existing use of DNS is as secure as possible
158 within the bounds of the relevant standards.
160 It should be noted that the most commonly used resolvers currently do
161 not perform as well as possible in this respect, making this document
162 of urgent importance.
164 A thorough analysis of risks facing DNS can be found in [RFC3833].
170Hubert & van Mook Standards Track [Page 3]
172RFC 5452 DNS Resilience against Forged Answers January 2009
175 This document expands on some of the risks mentioned in RFC 3833,
176 especially those outlined in the sections on "ID Guessing and Query
177 Prediction" and "Name Chaining". Furthermore, it emphasizes a number
178 of existing rules and guidelines embodied in the relevant DNS
179 protocol specifications. The following also specifies new
180 requirements to make sure the Domain Name System can be relied upon
181 until a more secure protocol has been standardized and deployed.
183 It should be noted that even when all measures suggested below are
184 implemented, protocol users are not protected against third parties
185 with the ability to observe, modify, or inject packets in the traffic
188 For protocol extensions that offer protection against these
189 scenarios, see [RFC4033] and beyond.
1912. Requirements and Definitions
195 This document uses the following definitions:
197 Client: typically a 'stub-resolver' on an end-user's computer.
199 Resolver: a nameserver performing recursive service for clients,
200 also known as a caching server, or a full service resolver
201 ([RFC1123], Section 6.1.3.1).
203 Stub resolver: a very limited resolver on a client computer, that
204 leaves the recursing work to a full resolver.
206 Query: a question sent out by a resolver, typically in a UDP
209 Response: the answer sent back by an authoritative nameserver,
210 typically in a UDP packet.
212 Third party: any entity other than the resolver or the intended
213 recipient of a question. The third party may have access to an
214 arbitrary authoritative nameserver, but has no access to packets
215 transmitted by the resolver or authoritative server.
217 Attacker: malicious third party.
219 Spoof: the activity of attempting to subvert the DNS process by
220 getting a chosen answer accepted.
226Hubert & van Mook Standards Track [Page 4]
228RFC 5452 DNS Resilience against Forged Answers January 2009
231 Authentic response: the correct answer that comes from the right
232 authoritative server.
234 Target domain name: domain for which the attacker wishes to spoof
237 Fake data: response chosen by the attacker.
241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
243 document are to be interpreted as described in [RFC2119].
2453. Description of DNS Spoofing
247 When certain steps are taken, it is feasible to "spoof" the current
248 deployed majority of resolvers with carefully crafted and timed DNS
249 packets. Once spoofed, a caching server will repeat the data it
250 wrongfully accepted, and make its clients contact the wrong, and
251 possibly malicious, servers.
253 To understand how this process works it is important to know what
254 makes a resolver accept a response.
256 The following sentence in Section 5.3.3 of [RFC1034] presaged the
259 The resolver should be highly paranoid in its parsing of responses.
260 It should also check that the response matches the query it sent
261 using the ID field in the response.
263 DNS data is to be accepted by a resolver if and only if:
265 1. The question section of the reply packet is equivalent to that of
266 a question packet currently waiting for a response.
268 2. The ID field of the reply packet matches that of the question
271 3. The response comes from the same network address to which the
274 4. The response comes in on the same network address, including port
275 number, from which the question was sent.
277 In general, the first response matching these four conditions is
282Hubert & van Mook Standards Track [Page 5]
284RFC 5452 DNS Resilience against Forged Answers January 2009
287 If a third party succeeds in meeting the four conditions before the
288 response from the authentic nameserver does so, it is in a position
289 to feed a resolver fabricated data. When it does so, we dub it an
290 "attacker", attempting to spoof in fake data.
292 All conditions mentioned above can theoretically be met by a third
293 party, with the difficulty being a function of the resolver
294 implementation and zone configuration.
2964. Detailed Description of Spoofing Scenarios
298 The previous paragraph discussed a number of requirements an attacker
299 must match in order to spoof in manipulated (or fake) data. This
300 section discusses the relative difficulties and how implementation-
301 defined choices impact the amount of work an attacker has to perform
302 to meet said difficulties.
304 Some more details can be found in Section 2.2 of [RFC3833].
308 Formally, there is no need for a nameserver to perform service except
309 for its operator, its customers, or more generally its users.
310 Recently, open recursing nameservers have been used to amplify
311 denial-of-service attacks.
313 Providing full service enables the third party to send the target
314 resolver a query for the domain name it intends to spoof. On
315 receiving this query, and not finding the answer in its cache, the
316 resolver will transmit queries to relevant authoritative nameservers.
317 This opens up a window of opportunity for getting fake answer data
320 Queries may however be forced indirectly, for example, by inducing a
321 mail server to perform DNS lookups.
323 Some operators restrict access by not recursing for unauthorized IP
324 addresses, but only respond with data from the cache. This makes
325 spoofing harder for a third party as it cannot then force the exact
326 moment a question will be asked. It is still possible however to
327 determine a time range when this will happen, because nameservers
328 helpfully publish the decreasing time to live (TTL) of entries in the
329 cache, which indicate from which absolute time onwards a new query
330 could be sent to refresh the expired entry.
332 The time to live of the target domain name's RRSets determines how
333 often a window of opportunity is available, which implies that a
334 short TTL makes spoofing far more viable.
338Hubert & van Mook Standards Track [Page 6]
340RFC 5452 DNS Resilience against Forged Answers January 2009
343 Note that the attacker might very well have authorized access to the
344 target resolver by virtue of being a customer or employee of its
345 operator. In addition, access may be enabled through the use of
346 reflectors as outlined in [RFC5358].
3484.2. Matching the Question Section
350 DNS packets, both queries and responses, contain a question section.
351 Incoming responses should be verified to have a question section that
352 is equivalent to that of the outgoing query.
3544.3. Matching the ID Field
356 The DNS ID field is 16 bits wide, meaning that if full use is made of
357 all these bits, and if their contents are truly random, it will
358 require on average 32768 attempts to guess. Anecdotal evidence
359 suggests there are implementations utilizing only 14 bits, meaning on
360 average 8192 attempts will suffice.
362 Additionally, if the target nameserver can be forced into having
363 multiple identical queries outstanding, the "Birthday Attack"
364 phenomenon means that any fake data sent by the attacker is matched
365 against multiple outstanding queries, significantly raising the
366 chance of success. Further details in Section 5.
3684.4. Matching the Source Address of the Authentic Response
370 It should be noted that meeting this condition entails being able to
371 transmit packets on behalf of the address of the authoritative
372 nameserver. While two Best Current Practice documents ([RFC2827] and
373 [RFC3013] specifically) direct Internet access providers to prevent
374 their customers from assuming IP addresses that are not assigned to
375 them, these recommendations are not universally (nor even widely)
378 Many zones have two or three authoritative nameservers, which make
379 matching the source address of the authentic response very likely
380 with even a naive choice having a double digit success rate.
382 Most recursing nameservers store relative performance indications of
383 authoritative nameservers, which may make it easier to predict which
384 nameserver would originally be queried -- the one most likely to
385 respond the quickest.
387 Generally, this condition requires at most two or three attempts
388 before it is matched.
394Hubert & van Mook Standards Track [Page 7]
396RFC 5452 DNS Resilience against Forged Answers January 2009
3994.5. Matching the Destination Address and Port of the Authentic
402 Note that the destination address of the authentic response is the
403 source address of the original query.
405 The actual address of a recursing nameserver is generally known; the
406 port used for asking questions is harder to determine. Most current
407 resolvers pick an arbitrary port at startup (possibly at random) and
408 use this for all outgoing queries. In quite a number of cases, the
409 source port of outgoing questions is fixed at the traditional DNS
410 assigned server port number of 53.
412 If the source port of the original query is random, but static, any
413 authoritative nameserver under observation by the attacker can be
414 used to determine this port. This means that matching this
415 conditions often requires no guess work.
417 If multiple ports are used for sending queries, this enlarges the
418 effective ID space by a factor equal to the number of ports used.
420 Less common resolving servers choose a random port per outgoing
421 query. If this strategy is followed, this port number can be
422 regarded as an additional ID field, again containing up to 16 bits.
424 If the maximum ports range is utilized, on average, around 32256
425 source ports would have to be tried before matching the source port
426 of the original query, as ports below 1024 may be unavailable for
427 use, leaving 64512 options.
429 It is in general safe for DNS to use ports in the range 1024-49152
430 even though some of these ports are allocated to other protocols.
431 DNS resolvers will not be able to use any ports that are already in
432 use. If a DNS resolver uses a port, it will release that port after
433 a short time and migrate to a different port. Only in the case of a
434 high-volume resolver is it possible that an application wanting a
435 particular UDP port suffers a long term block-out.
437 It should be noted that a firewall will not prevent the matching of
438 this address, as it will accept answers that (appear to) come from
439 the correct address, offering no additional security.
4414.6. Have the Response Arrive before the Authentic Response
443 Once any packet has matched the previous four conditions (plus
444 possible additional conditions), no further responses are generally
450Hubert & van Mook Standards Track [Page 8]
452RFC 5452 DNS Resilience against Forged Answers January 2009
455 This means that the third party has a limited time in which to inject
456 its spoofed response. For calculations, we will assume a window in
457 order of at most 100 ms (depending on the network distance to the
458 authentic authoritative nameserver).
460 This time period can be far longer if the authentic authoritative
461 nameservers are (briefly) overloaded by queries, perhaps by the
466 The so-called "birthday paradox" implies that a group of 23 people
467 suffices to have a more than even chance of having two or more
468 members of the group share a birthday.
470 An attacker can benefit from this exact phenomenon if it can force
471 the target resolver to have multiple equivalent (identical QNAME,
472 QTYPE, and QCLASS) outstanding queries at any one time to the same
473 authoritative server.
475 Any packet the attacker sends then has a much higher chance of being
476 accepted because it only has to match any of the outstanding queries
477 for that single domain. Compared to the birthday analogy above, of
478 the group composed of queries and responses, the chance of having any
479 of these share an ID rises quickly.
481 As long as small numbers of queries are sent out, the chance of
482 successfully spoofing a response rises linearly with the number of
483 outstanding queries for the exact domain and nameserver.
485 For larger numbers, this effect is less pronounced.
487 More details are available in US-CERT [vu-457875].
4896. Accepting Only In-Domain Records
491 Responses from authoritative nameservers often contain information
492 that is not part of the zone for which we deem it authoritative. As
493 an example, a query for the MX record of a domain might get as its
494 responses a mail exchanger in another domain, and additionally the IP
495 address of this mail exchanger.
497 If accepted uncritically, the resolver stands the chance of accepting
498 data from an untrusted source. Care must be taken to only accept
499 data if it is known that the originator is authoritative for the
500 QNAME or a parent of the QNAME.
506Hubert & van Mook Standards Track [Page 9]
508RFC 5452 DNS Resilience against Forged Answers January 2009
511 One very simple way to achieve this is to only accept data if it is
512 part of the domain for which the query was intended.
5147. Combined Difficulty
516 Given a known or static destination port, matching ID field, the
517 source and destination address requires on average in the order of 2
518 * 2^15 = 65000 packets, assuming a zone has 2 authoritative
521 If the window of opportunity available is around 100 ms, as assumed
522 above, an attacker would need to be able to briefly transmit 650000
523 packets/s to have a 50% chance to get spoofed data accepted on the
526 A realistic minimal DNS response consists of around 80 bytes,
527 including IP headers, making the packet rate above correspond to a
528 respectable burst of 416 Mbit/s.
530 As of mid-2006, this kind of bandwidth was not common but not scarce
531 either, especially among those in a position to control many servers.
533 These numbers change when a window of a full second is assumed,
534 possibly because the arrival of the authentic response can be
535 prevented by overloading the bona fide authoritative hosts with decoy
536 queries. This reduces the needed bandwidth to 42 Mbit/s.
538 If, in addition, the attacker is granted more than a single chance
539 and allowed up to 60 minutes of work on a domain with a time to live
540 of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at
541 getting fake data accepted. Once equipped with a longer time,
542 matching condition 1 mentioned above is straightforward -- any
543 popular domain will have been queried a number of times within this
544 hour, and given the short TTL, this would lead to queries to
545 authoritative nameservers, opening windows of opportunity.
5477.1. Symbols Used in Calculation
549 Assume the following symbols are used:
551 I: Number distinct IDs available (maximum 65536)
553 P: Number of ports used (maximum around 64000 as ports under 1024 are
554 not always available, but often 1)
556 N: Number of authoritative nameservers for a domain (averages around
562Hubert & van Mook Standards Track [Page 10]
564RFC 5452 DNS Resilience against Forged Answers January 2009
567 F: Number of "fake" packets sent by the attacker
569 R: Number of packets sent per second by the attacker
571 W: Window of opportunity, in seconds. Bounded by the response time
572 of the authoritative servers (often 0.1s)
574 D: Average number of identical outstanding queries of a resolver
575 (typically 1, see Section 5)
577 A: Number of attempts, one for each window of opportunity
581 The probability of spoofing a resolver is equal to the amount of fake
582 packets that arrive within the window of opportunity, divided by the
583 size of the problem space.
585 When the resolver has 'D' multiple identical outstanding queries,
586 each fake packet has a proportionally higher chance of matching any
587 of these queries. This assumption only holds for small values of
590 In symbols, if the probability of being spoofed is denoted as P_s:
596 It is more useful to reason not in terms of aggregate packets but to
597 convert to packet rate, which can easily be converted to bandwidth if
600 If the window of opportunity length is 'W' and the attacker can send
601 'R' packets per second, the number of fake packets 'F' that are
602 candidates to be accepted is:
605 F = R * W -> P_s = ---------
608 Finally, to calculate the combined chance 'P_cs' of spoofing over a
609 chosen time period 'T', it should be realized that the attacker has a
610 new window of opportunity each time the TTL 'TTL' of the target
611 domain expires. This means that the number of attempts 'A' is equal
618Hubert & van Mook Standards Track [Page 11]
620RFC 5452 DNS Resilience against Forged Answers January 2009
623 To calculate the combined chance of at least one success, the
624 following formula holds:
628 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- )
631 When common numbers (as listed above) for D, W, N, P, and I are
632 inserted, this formula reduces to:
636 P_cs = 1 - ( 1 - ------- )
639 From this formula, it can be seen that, if the nameserver
640 implementation is unchanged, only raising the TTL offers protection.
641 Raising N, the number of authoritative nameservers, is not feasible
642 beyond a small number.
644 For the degenerate case of a zero-second TTL, a window of opportunity
645 opens for each query sent, making the effective TTL equal to 'W'
646 above, the response time of the authoritative server.
648 This last case also holds for spoofing techniques that do not rely on
649 TTL expiry, but use repeated and changing queries.
653 The calculations above indicate the relative ease with which DNS data
654 can be spoofed. For example, using the formula derived earlier on an
655 RRSet with a 3600 second TTL, an attacker sending 7000 fake response
656 packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a
657 record in the first 24 hours, which rises to 50% after a week.
659 For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
660 minutes, 50% after less than 3 hours, 90% after around 9 hours.
662 For some classes of attacks, the effective TTL is near zero, as noted
665 Note that the attacks mentioned above can be detected by watchful
666 server operators - an unexpected incoming stream of 4.5 Mbit/s of
667 packets might be noticed.
669 An important assumption however in these calculations is a known or
670 static destination port of the authentic response.
674Hubert & van Mook Standards Track [Page 12]
676RFC 5452 DNS Resilience against Forged Answers January 2009
679 If that port number is unknown and needs to be guessed as well, the
680 problem space expands by a factor of 64000, leading the attacker to
681 need in excess of 285Gb/s to achieve similar success rates.
683 Such bandwidth is not generally available, nor is it expected to be
684 so in the foreseeable future.
686 Note that some firewalls may need reconfiguring if they are currently
687 set up to only allow outgoing queries from a single DNS source port.
6898.1. Repetitive Spoofing Attempts for a Single Domain Name
691 Techniques are available to use an effectively infinite number of
692 queries to achieve a desired spoofing goal. In the math above, this
693 reduces the effective TTL to 0.
695 If such techniques are employed, using the same 7000 packets/s rate
696 mentioned above, and using 1 source port, the spoofing chance rises
697 to 50% within 7 seconds.
699 If 64000 ports are used, as recommended in this document, using the
700 same query rate, the 50% level is reached after around 116 hours.
7029. Forgery Countermeasures
7049.1. Query Matching Rules
706 A resolver implementation MUST match responses to all of the
707 following attributes of the query:
709 o Source address against query destination address
711 o Destination address against query source address
713 o Destination port against query source port
719 o Query class and type
721 before applying DNS trustworthiness rules (see Section 5.4.1 of
724 A mismatch and the response MUST be considered invalid.
730Hubert & van Mook Standards Track [Page 13]
732RFC 5452 DNS Resilience against Forged Answers January 2009
7359.2. Extending the Q-ID Space by Using Ports and Addresses
737 Resolver implementations MUST:
739 o Use an unpredictable source port for outgoing queries from the
740 range of available ports (53, or 1024 and above) that is as large
741 as possible and practicable;
743 o Use multiple different source ports simultaneously in case of
744 multiple outstanding queries;
746 o Use an unpredictable query ID for outgoing queries, utilizing the
747 full range available (0-65535).
749 Resolvers that have multiple IP addresses SHOULD use them in an
750 unpredictable manner for outgoing queries.
752 Resolver implementations SHOULD provide means to avoid usage of
755 Resolvers SHOULD favor authoritative nameservers with which a trust
756 relation has been established; stub-resolvers SHOULD be able to use
757 Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
758 communicating with their recursive resolver.
760 In case a cryptographic verification of response validity is
761 available (TSIG, SIG(0)), resolver implementations MAY waive above
762 rules, and rely on this guarantee instead.
764 Proper unpredictability can be achieved by employing a high quality
765 (pseudo-)random generator, as described in [RFC4086].
7679.2.1. Justification and Discussion
769 Since an attacker can force a full DNS resolver to send queries to
770 the attacker's own nameservers, any constant or sequential state held
771 by such a resolver can be measured, and it must not be trivially easy
772 to reverse engineer the resolver's internal state in a way that
773 allows low-cost, high-accuracy prediction of future state.
775 A full DNS resolver with only one or a small number of upstream-
776 facing endpoints is effectively using constants for IP source address
777 and UDP port number, and these are very predictable by potential
778 attackers, and must therefore be avoided.
780 A full DNS resolver that uses a simple increment to get its next DNS
781 query ID is likewise very predictable and so very spoofable.
786Hubert & van Mook Standards Track [Page 14]
788RFC 5452 DNS Resilience against Forged Answers January 2009
791 Finally, weak random number generators have been shown to expose
792 their internal state, such that an attacker who witnesses several
793 sequential "random" values can easily predict the next ones. A
794 crypto-strength random number generator is one whose output cannot be
795 predicted no matter how many successive values are witnessed.
7979.3. Spoof Detection and Countermeasure
799 If a resolver detects that an attempt is being made to spoof it,
800 perhaps by discovering that many packets fail the criteria as
801 outlined above, it MAY abandon the UDP query and re-issue it over
802 TCP. TCP, by the nature of its use of sequence numbers, is far more
803 resilient against forgery by third parties.
80510. Security Considerations
807 This document provides clarification of the DNS specification to
808 decrease the probability that DNS responses can be successfully
809 forged. Recommendations found above should be considered
810 complementary to possible cryptographical enhancements of the domain
811 name system, which protect against a larger class of attacks.
813 This document recommends the use of UDP source port number
814 randomization to extend the effective DNS transaction ID beyond the
817 A resolver that does not implement the recommendations outlined above
818 can easily be forced to accept spoofed responses, which in turn are
819 passed on to client computers -- misdirecting (user) traffic to
820 possibly malicious entities.
822 This document directly impacts the security of the Domain Name
823 System, implementers are urged to follow its recommendations.
825 Most security considerations can be found in Sections 4 and 5, while
826 proposed countermeasures are described in Section 9.
828 For brevity's sake, in lieu of repeating the security considerations
829 references, the reader is referred to these sections.
831 Nothing in this document specifies specific algorithms for operators
832 to use; it does specify algorithms implementations SHOULD or MUST
835 It should be noted that the effects of source port randomization may
836 be dramatically reduced by NAT devices that either serialize or limit
837 in volume the UDP source ports used by the querying resolver.
842Hubert & van Mook Standards Track [Page 15]
844RFC 5452 DNS Resilience against Forged Answers January 2009
847 DNS recursive servers sitting behind at NAT or a statefull firewall
848 may consume all available NAT translation entries/ports when
849 operating under high query load. Port randomization will cause
850 translation entries to be consumed faster than with fixed query port.
852 To avoid this, NAT boxes and statefull firewalls can/should purge
853 outgoing DNS query translation entries 10-17 seconds after the last
854 outgoing query on that mapping was sent. [RFC4787]-compliant devices
855 need to treat UDP messages with port 53 differently than most other
858 To minimize the potential that port/state exhaustion attacks can be
859 staged from the outside, it is recommended that services that
860 generate a number of DNS queries for each connection should be rate
861 limited. This applies in particular to email servers.
865 Source port randomization in DNS was first implemented and possibly
866 invented by Dan J. Bernstein.
868 Although any mistakes remain our own, the authors gratefully
869 acknowledge the help and contributions of:
88212.1. Normative References
884 [RFC1034] Mockapetris, P., "Domain names - concepts and
885 facilities", STD 13, RFC 1034, November 1987.
887 [RFC1035] Mockapetris, P., "Domain names - implementation and
888 specification", STD 13, RFC 1035, November 1987.
890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
891 Requirement Levels", BCP 14, RFC 2119, March 1997.
893 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
894 Specification", RFC 2181, July 1997.
898Hubert & van Mook Standards Track [Page 16]
900RFC 5452 DNS Resilience against Forged Answers January 2009
903 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
904 Defeating Denial of Service Attacks which employ IP
905 Source Address Spoofing", BCP 38, RFC 2827, May 2000.
907 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
908 Wellington, "Secret Key Transaction Authentication for
909 DNS (TSIG)", RFC 2845, May 2000.
911 [RFC3013] Killalea, T., "Recommended Internet Service Provider
912 Security Services and Procedures", BCP 46, RFC 3013,
915 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
916 Rose, "DNS Security Introduction and Requirements",
917 RFC 4033, March 2005.
919 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
920 Requirements for Security", BCP 106, RFC 4086,
923 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
92612.2. Informative References
928 [RFC1123] Braden, R., "Requirements for Internet Hosts -
929 Application and Support", STD 3, RFC 1123, October 1989.
931 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
932 Domain Name System (DNS)", RFC 3833, August 2004.
934 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
935 Internet Protocol", RFC 4301, December 2005.
937 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
938 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
939 RFC 4787, January 2007.
941 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
942 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
945 [vu-457875] United States CERT, "Various DNS service implementations
946 generate multiple simultaneous queries for the same
947 resource record", VU 457875, November 2002.
954Hubert & van Mook Standards Track [Page 17]
956RFC 5452 DNS Resilience against Forged Answers January 2009
962 Netherlabs Computer Consulting BV.
964 Rijswijk (ZH) 2289 CM
967 EMail: bert.hubert@netherlabs.nl
976 EMail: remco@eu.equinix.com
1010Hubert & van Mook Standards Track [Page 18]