1 Network Working Group A. Hubert
2 Request for Comments: 5452 Netherlabs Computer Consulting BV.
3 Updates: 2181 R. van Mook
4 Category: Standards Track Equinix
5 January 2009
6
7
8 Measures for Making DNS More Resilient against Forged Answers
9
10 Status of This Memo
11
12 This document specifies an Internet standards track protocol for the
13 Internet community, and requests discussion and suggestions for
14 improvements. Please refer to the current edition of the "Internet
15 Official Protocol Standards" (STD 1) for the standardization state
16 and status of this protocol. Distribution of this memo is unlimited.
17
18 Copyright Notice
19
20 Copyright (c) 2009 IETF Trust and the persons identified as the
21 document authors. All rights reserved.
22
23 This document is subject to BCP 78 and the IETF Trust's Legal
24 Provisions Relating to IETF Documents (http://trustee.ietf.org/
25 license-info) in effect on the date of publication of this document.
26 Please review these documents carefully, as they describe your rights
27 and restrictions with respect to this document.
28
29 Abstract
30
31 The current Internet climate poses serious threats to the Domain Name
32 System. In the interim period before the DNS protocol can be secured
33 more fully, measures can already be taken to harden the DNS to make
34 'spoofing' a recursing nameserver many orders of magnitude harder.
35
36 Even a cryptographically secured DNS benefits from having the ability
37 to discard bogus responses quickly, as this potentially saves large
38 amounts of computation.
39
40 By describing certain behavior that has previously not been
41 standardized, this document sets out how to make the DNS more
42 resilient against accepting incorrect responses. This document
43 updates RFC 2181.
44
45
46
47
48
49
50
51
52 Hubert & van Mook Standards Track [Page 1]
53 RFC 5452 DNS Resilience against Forged Answers January 2009
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4
60 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
61 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5
62 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5
63 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6
64 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6
65 4.2. Matching the Question Section . . . . . . . . . . . . . . 7
66 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7
67 4.4. Matching the Source Address of the Authentic Response . . 7
68 4.5. Matching the Destination Address and Port of the
69 Authentic Response . . . . . . . . . . . . . . . . . . . . 8
70 4.6. Have the Response Arrive before the Authentic Response . . 8
71 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9
72 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9
73 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10
74 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10
75 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11
76 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
77 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13
78 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13
79 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
80 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14
81 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14
82 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15
83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
87 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Hubert & van Mook Standards Track [Page 2]
108 RFC 5452 DNS Resilience against Forged Answers January 2009
109
110
111 1. Introduction
112
113 This document describes several common problems in DNS
114 implementations, which, although previously recognized, remain
115 largely unsolved. Besides briefly recapping these problems, this
116 document contains rules that, if implemented, make complying
117 resolvers vastly more resistant to the attacks described. The goal
118 is to make the existing DNS as secure as possible within the current
119 protocol boundaries.
120
121 The words below are aimed at authors of resolvers: it is up to
122 operators to decide which nameserver implementation to use, or which
123 options to enable. Operational constraints may override the security
124 concerns described below. However, implementations are expected to
125 allow an operator to enable functionality described in this document.
126
127 Almost every transaction on the Internet involves the Domain Name
128 System, which is described in [RFC1034], [RFC1035], and beyond.
129
130 Additionally, it has recently become possible to acquire Secure
131 Socket Layer/Transport Layer Security (SSL/TLS) certificates with no
132 other confirmation of identity than the ability to respond to a
133 verification email sent via SMTP ([RFC5321]) -- which generally uses
134 DNS for its routing.
135
136 In other words, any party that (temporarily) controls the Domain Name
137 System is in a position to reroute most kinds of Internet
138 transactions, including the verification steps in acquiring an SSL/
139 TLS certificate for a domain. This in turn means that even
140 transactions protected by SSL/TLS could be diverted.
141
142 It is entirely conceivable that such rerouted traffic could be used
143 to the disadvantage of Internet users.
144
145 These and other developments have made the security and
146 trustworthiness of DNS of renewed importance. Although the DNS
147 community is working hard on finalizing and implementing a
148 cryptographically enhanced DNS protocol, steps should be taken to
149 make sure that the existing use of DNS is as secure as possible
150 within the bounds of the relevant standards.
151
152 It should be noted that the most commonly used resolvers currently do
153 not perform as well as possible in this respect, making this document
154 of urgent importance.
155
156 A thorough analysis of risks facing DNS can be found in [RFC3833].
157
158
159
160
161
162 Hubert & van Mook Standards Track [Page 3]
163 RFC 5452 DNS Resilience against Forged Answers January 2009
164
165
166 This document expands on some of the risks mentioned in RFC 3833,
167 especially those outlined in the sections on "ID Guessing and Query
168 Prediction" and "Name Chaining". Furthermore, it emphasizes a number
169 of existing rules and guidelines embodied in the relevant DNS
170 protocol specifications. The following also specifies new
171 requirements to make sure the Domain Name System can be relied upon
172 until a more secure protocol has been standardized and deployed.
173
174 It should be noted that even when all measures suggested below are
175 implemented, protocol users are not protected against third parties
176 with the ability to observe, modify, or inject packets in the traffic
177 of a resolver.
178
179 For protocol extensions that offer protection against these
180 scenarios, see [RFC4033] and beyond.
181
182 2. Requirements and Definitions
183
184 2.1. Definitions
185
186 This document uses the following definitions:
187
188 Client: typically a 'stub-resolver' on an end-user's computer.
189
190 Resolver: a nameserver performing recursive service for clients,
191 also known as a caching server, or a full service resolver
192 ([RFC1123], Section 6.1.3.1).
193
194 Stub resolver: a very limited resolver on a client computer, that
195 leaves the recursing work to a full resolver.
196
197 Query: a question sent out by a resolver, typically in a UDP
198 packet
199
200 Response: the answer sent back by an authoritative nameserver,
201 typically in a UDP packet.
202
203 Third party: any entity other than the resolver or the intended
204 recipient of a question. The third party may have access to an
205 arbitrary authoritative nameserver, but has no access to packets
206 transmitted by the resolver or authoritative server.
207
208 Attacker: malicious third party.
209
210 Spoof: the activity of attempting to subvert the DNS process by
211 getting a chosen answer accepted.
212
213
214
215
216
217 Hubert & van Mook Standards Track [Page 4]
218 RFC 5452 DNS Resilience against Forged Answers January 2009
219
220
221 Authentic response: the correct answer that comes from the right
222 authoritative server.
223
224 Target domain name: domain for which the attacker wishes to spoof
225 in an answer
226
227 Fake data: response chosen by the attacker.
228
229 2.2. Key Words
230
231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
233 document are to be interpreted as described in [RFC2119].
234
235 3. Description of DNS Spoofing
236
237 When certain steps are taken, it is feasible to "spoof" the current
238 deployed majority of resolvers with carefully crafted and timed DNS
239 packets. Once spoofed, a caching server will repeat the data it
240 wrongfully accepted, and make its clients contact the wrong, and
241 possibly malicious, servers.
242
243 To understand how this process works it is important to know what
244 makes a resolver accept a response.
245
246 The following sentence in Section 5.3.3 of [RFC1034] presaged the
247 present problem:
248
249 The resolver should be highly paranoid in its parsing of responses.
250 It should also check that the response matches the query it sent
251 using the ID field in the response.
252
253 DNS data is to be accepted by a resolver if and only if:
254
255 1. The question section of the reply packet is equivalent to that of
256 a question packet currently waiting for a response.
257
258 2. The ID field of the reply packet matches that of the question
259 packet.
260
261 3. The response comes from the same network address to which the
262 question was sent.
263
264 4. The response comes in on the same network address, including port
265 number, from which the question was sent.
266
267 In general, the first response matching these four conditions is
268 accepted.
269
270
271
272 Hubert & van Mook Standards Track [Page 5]
273 RFC 5452 DNS Resilience against Forged Answers January 2009
274
275
276 If a third party succeeds in meeting the four conditions before the
277 response from the authentic nameserver does so, it is in a position
278 to feed a resolver fabricated data. When it does so, we dub it an
279 "attacker", attempting to spoof in fake data.
280
281 All conditions mentioned above can theoretically be met by a third
282 party, with the difficulty being a function of the resolver
283 implementation and zone configuration.
284
285 4. Detailed Description of Spoofing Scenarios
286
287 The previous paragraph discussed a number of requirements an attacker
288 must match in order to spoof in manipulated (or fake) data. This
289 section discusses the relative difficulties and how implementation-
290 defined choices impact the amount of work an attacker has to perform
291 to meet said difficulties.
292
293 Some more details can be found in Section 2.2 of [RFC3833].
294
295 4.1. Forcing a Query
296
297 Formally, there is no need for a nameserver to perform service except
298 for its operator, its customers, or more generally its users.
299 Recently, open recursing nameservers have been used to amplify
300 denial-of-service attacks.
301
302 Providing full service enables the third party to send the target
303 resolver a query for the domain name it intends to spoof. On
304 receiving this query, and not finding the answer in its cache, the
305 resolver will transmit queries to relevant authoritative nameservers.
306 This opens up a window of opportunity for getting fake answer data
307 accepted.
308
309 Queries may however be forced indirectly, for example, by inducing a
310 mail server to perform DNS lookups.
311
312 Some operators restrict access by not recursing for unauthorized IP
313 addresses, but only respond with data from the cache. This makes
314 spoofing harder for a third party as it cannot then force the exact
315 moment a question will be asked. It is still possible however to
316 determine a time range when this will happen, because nameservers
317 helpfully publish the decreasing time to live (TTL) of entries in the
318 cache, which indicate from which absolute time onwards a new query
319 could be sent to refresh the expired entry.
320
321 The time to live of the target domain name's RRSets determines how
322 often a window of opportunity is available, which implies that a
323 short TTL makes spoofing far more viable.
324
325
326
327 Hubert & van Mook Standards Track [Page 6]
328 RFC 5452 DNS Resilience against Forged Answers January 2009
329
330
331 Note that the attacker might very well have authorized access to the
332 target resolver by virtue of being a customer or employee of its
333 operator. In addition, access may be enabled through the use of
334 reflectors as outlined in [RFC5358].
335
336 4.2. Matching the Question Section
337
338 DNS packets, both queries and responses, contain a question section.
339 Incoming responses should be verified to have a question section that
340 is equivalent to that of the outgoing query.
341
342 4.3. Matching the ID Field
343
344 The DNS ID field is 16 bits wide, meaning that if full use is made of
345 all these bits, and if their contents are truly random, it will
346 require on average 32768 attempts to guess. Anecdotal evidence
347 suggests there are implementations utilizing only 14 bits, meaning on
348 average 8192 attempts will suffice.
349
350 Additionally, if the target nameserver can be forced into having
351 multiple identical queries outstanding, the "Birthday Attack"
352 phenomenon means that any fake data sent by the attacker is matched
353 against multiple outstanding queries, significantly raising the
354 chance of success. Further details in Section 5.
355
356 4.4. Matching the Source Address of the Authentic Response
357
358 It should be noted that meeting this condition entails being able to
359 transmit packets on behalf of the address of the authoritative
360 nameserver. While two Best Current Practice documents ([RFC2827] and
361 [RFC3013] specifically) direct Internet access providers to prevent
362 their customers from assuming IP addresses that are not assigned to
363 them, these recommendations are not universally (nor even widely)
364 implemented.
365
366 Many zones have two or three authoritative nameservers, which make
367 matching the source address of the authentic response very likely
368 with even a naive choice having a double digit success rate.
369
370 Most recursing nameservers store relative performance indications of
371 authoritative nameservers, which may make it easier to predict which
372 nameserver would originally be queried -- the one most likely to
373 respond the quickest.
374
375 Generally, this condition requires at most two or three attempts
376 before it is matched.
377
378
379
380
381
382 Hubert & van Mook Standards Track [Page 7]
383 RFC 5452 DNS Resilience against Forged Answers January 2009
384
385
386 4.5. Matching the Destination Address and Port of the Authentic
387 Response
388
389 Note that the destination address of the authentic response is the
390 source address of the original query.
391
392 The actual address of a recursing nameserver is generally known; the
393 port used for asking questions is harder to determine. Most current
394 resolvers pick an arbitrary port at startup (possibly at random) and
395 use this for all outgoing queries. In quite a number of cases, the
396 source port of outgoing questions is fixed at the traditional DNS
397 assigned server port number of 53.
398
399 If the source port of the original query is random, but static, any
400 authoritative nameserver under observation by the attacker can be
401 used to determine this port. This means that matching this
402 conditions often requires no guess work.
403
404 If multiple ports are used for sending queries, this enlarges the
405 effective ID space by a factor equal to the number of ports used.
406
407 Less common resolving servers choose a random port per outgoing
408 query. If this strategy is followed, this port number can be
409 regarded as an additional ID field, again containing up to 16 bits.
410
411 If the maximum ports range is utilized, on average, around 32256
412 source ports would have to be tried before matching the source port
413 of the original query, as ports below 1024 may be unavailable for
414 use, leaving 64512 options.
415
416 It is in general safe for DNS to use ports in the range 1024-49152
417 even though some of these ports are allocated to other protocols.
418 DNS resolvers will not be able to use any ports that are already in
419 use. If a DNS resolver uses a port, it will release that port after
420 a short time and migrate to a different port. Only in the case of a
421 high-volume resolver is it possible that an application wanting a
422 particular UDP port suffers a long term block-out.
423
424 It should be noted that a firewall will not prevent the matching of
425 this address, as it will accept answers that (appear to) come from
426 the correct address, offering no additional security.
427
428 4.6. Have the Response Arrive before the Authentic Response
429
430 Once any packet has matched the previous four conditions (plus
431 possible additional conditions), no further responses are generally
432 accepted.
433
434
435
436
437 Hubert & van Mook Standards Track [Page 8]
438 RFC 5452 DNS Resilience against Forged Answers January 2009
439
440
441 This means that the third party has a limited time in which to inject
442 its spoofed response. For calculations, we will assume a window in
443 order of at most 100 ms (depending on the network distance to the
444 authentic authoritative nameserver).
445
446 This time period can be far longer if the authentic authoritative
447 nameservers are (briefly) overloaded by queries, perhaps by the
448 attacker.
449
450 5. Birthday Attacks
451
452 The so-called "birthday paradox" implies that a group of 23 people
453 suffices to have a more than even chance of having two or more
454 members of the group share a birthday.
455
456 An attacker can benefit from this exact phenomenon if it can force
457 the target resolver to have multiple equivalent (identical QNAME,
458 QTYPE, and QCLASS) outstanding queries at any one time to the same
459 authoritative server.
460
461 Any packet the attacker sends then has a much higher chance of being
462 accepted because it only has to match any of the outstanding queries
463 for that single domain. Compared to the birthday analogy above, of
464 the group composed of queries and responses, the chance of having any
465 of these share an ID rises quickly.
466
467 As long as small numbers of queries are sent out, the chance of
468 successfully spoofing a response rises linearly with the number of
469 outstanding queries for the exact domain and nameserver.
470
471 For larger numbers, this effect is less pronounced.
472
473 More details are available in US-CERT [vu-457875].
474
475 6. Accepting Only In-Domain Records
476
477 Responses from authoritative nameservers often contain information
478 that is not part of the zone for which we deem it authoritative. As
479 an example, a query for the MX record of a domain might get as its
480 responses a mail exchanger in another domain, and additionally the IP
481 address of this mail exchanger.
482
483 If accepted uncritically, the resolver stands the chance of accepting
484 data from an untrusted source. Care must be taken to only accept
485 data if it is known that the originator is authoritative for the
486 QNAME or a parent of the QNAME.
487
488
489
490
491
492 Hubert & van Mook Standards Track [Page 9]
493 RFC 5452 DNS Resilience against Forged Answers January 2009
494
495
496 One very simple way to achieve this is to only accept data if it is
497 part of the domain for which the query was intended.
498
499 7. Combined Difficulty
500
501 Given a known or static destination port, matching ID field, the
502 source and destination address requires on average in the order of 2
503 * 2^15 = 65000 packets, assuming a zone has 2 authoritative
504 nameservers.
505
506 If the window of opportunity available is around 100 ms, as assumed
507 above, an attacker would need to be able to briefly transmit 650000
508 packets/s to have a 50% chance to get spoofed data accepted on the
509 first attempt.
510
511 A realistic minimal DNS response consists of around 80 bytes,
512 including IP headers, making the packet rate above correspond to a
513 respectable burst of 416 Mbit/s.
514
515 As of mid-2006, this kind of bandwidth was not common but not scarce
516 either, especially among those in a position to control many servers.
517
518 These numbers change when a window of a full second is assumed,
519 possibly because the arrival of the authentic response can be
520 prevented by overloading the bona fide authoritative hosts with decoy
521 queries. This reduces the needed bandwidth to 42 Mbit/s.
522
523 If, in addition, the attacker is granted more than a single chance
524 and allowed up to 60 minutes of work on a domain with a time to live
525 of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at
526 getting fake data accepted. Once equipped with a longer time,
527 matching condition 1 mentioned above is straightforward -- any
528 popular domain will have been queried a number of times within this
529 hour, and given the short TTL, this would lead to queries to
530 authoritative nameservers, opening windows of opportunity.
531
532 7.1. Symbols Used in Calculation
533
534 Assume the following symbols are used:
535
536 I: Number distinct IDs available (maximum 65536)
537
538 P: Number of ports used (maximum around 64000 as ports under 1024 are
539 not always available, but often 1)
540
541 N: Number of authoritative nameservers for a domain (averages around
542 2.5)
543
544
545
546
547 Hubert & van Mook Standards Track [Page 10]
548 RFC 5452 DNS Resilience against Forged Answers January 2009
549
550
551 F: Number of "fake" packets sent by the attacker
552
553 R: Number of packets sent per second by the attacker
554
555 W: Window of opportunity, in seconds. Bounded by the response time
556 of the authoritative servers (often 0.1s)
557
558 D: Average number of identical outstanding queries of a resolver
559 (typically 1, see Section 5)
560
561 A: Number of attempts, one for each window of opportunity
562
563 7.2. Calculation
564
565 The probability of spoofing a resolver is equal to the amount of fake
566 packets that arrive within the window of opportunity, divided by the
567 size of the problem space.
568
569 When the resolver has 'D' multiple identical outstanding queries,
570 each fake packet has a proportionally higher chance of matching any
571 of these queries. This assumption only holds for small values of
572 'D'.
573
574 In symbols, if the probability of being spoofed is denoted as P_s:
575
576 D * F
577 P_s = ---------
578 N * P * I
579
580 It is more useful to reason not in terms of aggregate packets but to
581 convert to packet rate, which can easily be converted to bandwidth if
582 needed.
583
584 If the window of opportunity length is 'W' and the attacker can send
585 'R' packets per second, the number of fake packets 'F' that are
586 candidates to be accepted is:
587
588 D * R * W
589 F = R * W -> P_s = ---------
590 N * P * I
591
592 Finally, to calculate the combined chance 'P_cs' of spoofing over a
593 chosen time period 'T', it should be realized that the attacker has a
594 new window of opportunity each time the TTL 'TTL' of the target
595 domain expires. This means that the number of attempts 'A' is equal
596 to 'T / TTL'.
597
598
599
600
601
602 Hubert & van Mook Standards Track [Page 11]
603 RFC 5452 DNS Resilience against Forged Answers January 2009
604
605
606 To calculate the combined chance of at least one success, the
607 following formula holds:
608
609 (T / TTL)
610 A ( D * R * W )
611 P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- )
612 ( N * P * I )
613
614 When common numbers (as listed above) for D, W, N, P, and I are
615 inserted, this formula reduces to:
616
617 (T / TTL)
618 ( R )
619 P_cs = 1 - ( 1 - ------- )
620 ( 1638400 )
621
622 From this formula, it can be seen that, if the nameserver
623 implementation is unchanged, only raising the TTL offers protection.
624 Raising N, the number of authoritative nameservers, is not feasible
625 beyond a small number.
626
627 For the degenerate case of a zero-second TTL, a window of opportunity
628 opens for each query sent, making the effective TTL equal to 'W'
629 above, the response time of the authoritative server.
630
631 This last case also holds for spoofing techniques that do not rely on
632 TTL expiry, but use repeated and changing queries.
633
634 8. Discussion
635
636 The calculations above indicate the relative ease with which DNS data
637 can be spoofed. For example, using the formula derived earlier on an
638 RRSet with a 3600 second TTL, an attacker sending 7000 fake response
639 packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a
640 record in the first 24 hours, which rises to 50% after a week.
641
642 For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
643 minutes, 50% after less than 3 hours, 90% after around 9 hours.
644
645 For some classes of attacks, the effective TTL is near zero, as noted
646 above.
647
648 Note that the attacks mentioned above can be detected by watchful
649 server operators - an unexpected incoming stream of 4.5 Mbit/s of
650 packets might be noticed.
651
652 An important assumption however in these calculations is a known or
653 static destination port of the authentic response.
654
655
656
657 Hubert & van Mook Standards Track [Page 12]
658 RFC 5452 DNS Resilience against Forged Answers January 2009
659
660
661 If that port number is unknown and needs to be guessed as well, the
662 problem space expands by a factor of 64000, leading the attacker to
663 need in excess of 285Gb/s to achieve similar success rates.
664
665 Such bandwidth is not generally available, nor is it expected to be
666 so in the foreseeable future.
667
668 Note that some firewalls may need reconfiguring if they are currently
669 set up to only allow outgoing queries from a single DNS source port.
670
671 8.1. Repetitive Spoofing Attempts for a Single Domain Name
672
673 Techniques are available to use an effectively infinite number of
674 queries to achieve a desired spoofing goal. In the math above, this
675 reduces the effective TTL to 0.
676
677 If such techniques are employed, using the same 7000 packets/s rate
678 mentioned above, and using 1 source port, the spoofing chance rises
679 to 50% within 7 seconds.
680
681 If 64000 ports are used, as recommended in this document, using the
682 same query rate, the 50% level is reached after around 116 hours.
683
684 9. Forgery Countermeasures
685
686 9.1. Query Matching Rules
687
688 A resolver implementation MUST match responses to all of the
689 following attributes of the query:
690
691 o Source address against query destination address
692
693 o Destination address against query source address
694
695 o Destination port against query source port
696
697 o Query ID
698
699 o Query name
700
701 o Query class and type
702
703 before applying DNS trustworthiness rules (see Section 5.4.1 of
704 [RFC2181]).
705
706 A mismatch and the response MUST be considered invalid.
707
708
709
710
711
712 Hubert & van Mook Standards Track [Page 13]
713 RFC 5452 DNS Resilience against Forged Answers January 2009
714
715
716 9.2. Extending the Q-ID Space by Using Ports and Addresses
717
718 Resolver implementations MUST:
719
720 o Use an unpredictable source port for outgoing queries from the
721 range of available ports (53, or 1024 and above) that is as large
722 as possible and practicable;
723
724 o Use multiple different source ports simultaneously in case of
725 multiple outstanding queries;
726
727 o Use an unpredictable query ID for outgoing queries, utilizing the
728 full range available (0-65535).
729
730 Resolvers that have multiple IP addresses SHOULD use them in an
731 unpredictable manner for outgoing queries.
732
733 Resolver implementations SHOULD provide means to avoid usage of
734 certain ports.
735
736 Resolvers SHOULD favor authoritative nameservers with which a trust
737 relation has been established; stub-resolvers SHOULD be able to use
738 Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
739 communicating with their recursive resolver.
740
741 In case a cryptographic verification of response validity is
742 available (TSIG, SIG(0)), resolver implementations MAY waive above
743 rules, and rely on this guarantee instead.
744
745 Proper unpredictability can be achieved by employing a high quality
746 (pseudo-)random generator, as described in [RFC4086].
747
748 9.2.1. Justification and Discussion
749
750 Since an attacker can force a full DNS resolver to send queries to
751 the attacker's own nameservers, any constant or sequential state held
752 by such a resolver can be measured, and it must not be trivially easy
753 to reverse engineer the resolver's internal state in a way that
754 allows low-cost, high-accuracy prediction of future state.
755
756 A full DNS resolver with only one or a small number of upstream-
757 facing endpoints is effectively using constants for IP source address
758 and UDP port number, and these are very predictable by potential
759 attackers, and must therefore be avoided.
760
761 A full DNS resolver that uses a simple increment to get its next DNS
762 query ID is likewise very predictable and so very spoofable.
763
764
765
766
767 Hubert & van Mook Standards Track [Page 14]
768 RFC 5452 DNS Resilience against Forged Answers January 2009
769
770
771 Finally, weak random number generators have been shown to expose
772 their internal state, such that an attacker who witnesses several
773 sequential "random" values can easily predict the next ones. A
774 crypto-strength random number generator is one whose output cannot be
775 predicted no matter how many successive values are witnessed.
776
777 9.3. Spoof Detection and Countermeasure
778
779 If a resolver detects that an attempt is being made to spoof it,
780 perhaps by discovering that many packets fail the criteria as
781 outlined above, it MAY abandon the UDP query and re-issue it over
782 TCP. TCP, by the nature of its use of sequence numbers, is far more
783 resilient against forgery by third parties.
784
785 10. Security Considerations
786
787 This document provides clarification of the DNS specification to
788 decrease the probability that DNS responses can be successfully
789 forged. Recommendations found above should be considered
790 complementary to possible cryptographical enhancements of the domain
791 name system, which protect against a larger class of attacks.
792
793 This document recommends the use of UDP source port number
794 randomization to extend the effective DNS transaction ID beyond the
795 available 16 bits.
796
797 A resolver that does not implement the recommendations outlined above
798 can easily be forced to accept spoofed responses, which in turn are
799 passed on to client computers -- misdirecting (user) traffic to
800 possibly malicious entities.
801
802 This document directly impacts the security of the Domain Name
803 System, implementers are urged to follow its recommendations.
804
805 Most security considerations can be found in Sections 4 and 5, while
806 proposed countermeasures are described in Section 9.
807
808 For brevity's sake, in lieu of repeating the security considerations
809 references, the reader is referred to these sections.
810
811 Nothing in this document specifies specific algorithms for operators
812 to use; it does specify algorithms implementations SHOULD or MUST
813 support.
814
815 It should be noted that the effects of source port randomization may
816 be dramatically reduced by NAT devices that either serialize or limit
817 in volume the UDP source ports used by the querying resolver.
818
819
820
821
822 Hubert & van Mook Standards Track [Page 15]
823 RFC 5452 DNS Resilience against Forged Answers January 2009
824
825
826 DNS recursive servers sitting behind at NAT or a statefull firewall
827 may consume all available NAT translation entries/ports when
828 operating under high query load. Port randomization will cause
829 translation entries to be consumed faster than with fixed query port.
830
831 To avoid this, NAT boxes and statefull firewalls can/should purge
832 outgoing DNS query translation entries 10-17 seconds after the last
833 outgoing query on that mapping was sent. [RFC4787]-compliant devices
834 need to treat UDP messages with port 53 differently than most other
835 UDP protocols.
836
837 To minimize the potential that port/state exhaustion attacks can be
838 staged from the outside, it is recommended that services that
839 generate a number of DNS queries for each connection should be rate
840 limited. This applies in particular to email servers.
841
842 11. Acknowledgments
843
844 Source port randomization in DNS was first implemented and possibly
845 invented by Dan J. Bernstein.
846
847 Although any mistakes remain our own, the authors gratefully
848 acknowledge the help and contributions of:
849 Stephane Bortzmeyer
850 Alfred Hoenes
851 Peter Koch
852 Sean Leach
853 Norbert Sendetzky
854 Paul Vixie
855 Florian Weimer
856 Wouter Wijngaards
857 Dan Wing
858
859 12. References
860
861 12.1. Normative References
862
863 [RFC1034] Mockapetris, P., "Domain names - concepts and
864 facilities", STD 13, RFC 1034, November 1987.
865
866 [RFC1035] Mockapetris, P., "Domain names - implementation and
867 specification", STD 13, RFC 1035, November 1987.
868
869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
870 Requirement Levels", BCP 14, RFC 2119, March 1997.
871
872 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
873 Specification", RFC 2181, July 1997.
874
875
876
877 Hubert & van Mook Standards Track [Page 16]
878 RFC 5452 DNS Resilience against Forged Answers January 2009
879
880
881 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
882 Defeating Denial of Service Attacks which employ IP
883 Source Address Spoofing", BCP 38, RFC 2827, May 2000.
884
885 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
886 Wellington, "Secret Key Transaction Authentication for
887 DNS (TSIG)", RFC 2845, May 2000.
888
889 [RFC3013] Killalea, T., "Recommended Internet Service Provider
890 Security Services and Procedures", BCP 46, RFC 3013,
891 November 2000.
892
893 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
894 Rose, "DNS Security Introduction and Requirements",
895 RFC 4033, March 2005.
896
897 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
898 Requirements for Security", BCP 106, RFC 4086,
899 June 2005.
900
901 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
902 October 2008.
903
904 12.2. Informative References
905
906 [RFC1123] Braden, R., "Requirements for Internet Hosts -
907 Application and Support", STD 3, RFC 1123, October 1989.
908
909 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
910 Domain Name System (DNS)", RFC 3833, August 2004.
911
912 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
913 Internet Protocol", RFC 4301, December 2005.
914
915 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
916 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
917 RFC 4787, January 2007.
918
919 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
920 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
921 October 2008.
922
923 [vu-457875] United States CERT, "Various DNS service implementations
924 generate multiple simultaneous queries for the same
925 resource record", VU 457875, November 2002.
926
927
928
929
930
931
932 Hubert & van Mook Standards Track [Page 17]
933 RFC 5452 DNS Resilience against Forged Answers January 2009
934
935
936 Authors' Addresses
937
938 Bert Hubert
939 Netherlabs Computer Consulting BV.
940 Braillelaan 10
941 Rijswijk (ZH) 2289 CM
942 The Netherlands
943
944 EMail: bert.hubert@netherlabs.nl
945
946
947 Remco van Mook
948 Equinix
949 Auke Vleerstraat 1
950 Enschede 7521 PE
951 The Netherlands
952
953 EMail: remco@eu.equinix.com
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987 Hubert & van Mook Standards Track [Page 18]
988
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions). named only uses ports to extend the ID space; addresses are not used.