7Network Working Group D. Atkins
8Request for Comments: 3833 IHTFP Consulting
9Category: Informational R. Austein
14 Threat Analysis of the Domain Name System (DNS)
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (2004).
28 Although the DNS Security Extensions (DNSSEC) have been under
29 development for most of the last decade, the IETF has never written
30 down the specific set of threats against which DNSSEC is designed to
31 protect. Among other drawbacks, this cart-before-the-horse situation
32 has made it difficult to determine whether DNSSEC meets its design
33 goals, since its design goals are not well specified. This note
34 attempts to document some of the known threats to the DNS, and, in
35 doing so, attempts to measure to what extent (if any) DNSSEC is a
36 useful tool in defending against these threats.
40 The earliest organized work on DNSSEC within the IETF was an open
41 design team meeting organized by members of the DNS working group in
42 November 1993 at the 28th IETF meeting in Houston. The broad
43 outlines of DNSSEC as we know it today are already clear in Jim
44 Galvin's summary of the results of that meeting [Galvin93]:
46 - While some participants in the meeting were interested in
47 protecting against disclosure of DNS data to unauthorized parties,
48 the design team made an explicit decision that "DNS data is
49 `public'", and ruled all threats of data disclosure explicitly out
52 - While some participants in the meeting were interested in
53 authentication of DNS clients and servers as a basis for access
54 control, this work was also ruled out of scope for DNSSEC per se.
58Atkins & Austein Informational [Page 1]
60RFC 3833 DNS Threat Analysis August 2004
63 - Backwards compatibility and co-existence with "insecure DNS" was
64 listed as an explicit requirement.
66 - The resulting list of desired security services was
67 1) data integrity, and
68 2) data origin authentication.
70 - The design team noted that a digital signature mechanism would
71 support the desired services.
73 While a number of detail decisions were yet to be made (and in some
74 cases remade after implementation experience) over the subsequent
75 decade, the basic model and design goals have remained fixed.
77 Nowhere, however, does any of the DNSSEC work attempt to specify in
78 any detail the sorts of attacks against which DNSSEC is intended to
79 protect, or the reasons behind the list of desired security services
80 that came out of the Houston meeting. For that, we have to go back
81 to a paper originally written by Steve Bellovin in 1990 but not
82 published until 1995, for reasons that Bellovin explained in the
83 paper's epilogue [Bellovin95].
85 While it may seem a bit strange to publish the threat analysis a
86 decade after starting work on the protocol designed to defend against
87 it, that is, nevertheless, what this note attempts to do. Better
90 This note assumes that the reader is familiar with both the DNS and
91 with DNSSEC, and does not attempt to provide a tutorial on either.
92 The DNS documents most relevant to the subject of this note are:
93 [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
94 [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
96 For purposes of discussion, this note uses the term "DNSSEC" to refer
97 to the core hierarchical public key and signature mechanism specified
98 in the DNSSEC documents, and refers to TKEY and TSIG as separate
99 mechanisms, even though channel security mechanisms such as TKEY and
100 TSIG are also part of the larger problem of "securing DNS" and thus
101 are often considered part of the overall set of "DNS security
102 extensions". This is an arbitrary distinction that in part reflects
103 the way in which the protocol has evolved (introduction of a
104 putatively simpler channel security model for certain operations such
105 as zone transfers and dynamic update requests), and perhaps should be
106 changed in a future revision of this note.
114Atkins & Austein Informational [Page 2]
116RFC 3833 DNS Threat Analysis August 2004
121 There are several distinct classes of threats to the DNS, most of
122 which are DNS-related instances of more general problems, but a few
123 of which are specific to peculiarities of the DNS protocol.
1252.1. Packet Interception
127 Some of the simplest threats against DNS are various forms of packet
128 interception: monkey-in-the-middle attacks, eavesdropping on requests
129 combined with spoofed responses that beat the real response back to
130 the resolver, and so forth. In any of these scenarios, the attacker
131 can simply tell either party (usually the resolver) whatever it wants
132 that party to believe. While packet interception attacks are far
133 from unique to DNS, DNS's usual behavior of sending an entire query
134 or response in a single unsigned, unencrypted UDP packet makes these
135 attacks particularly easy for any bad guy with the ability to
136 intercept packets on a shared or transit network.
138 To further complicate things, the DNS query the attacker intercepts
139 may just be a means to an end for the attacker: the attacker might
140 even choose to return the correct result in the answer section of a
141 reply message while using other parts of the message to set the stage
142 for something more complicated, for example, a name chaining attack
145 While it certainly would be possible to sign DNS messages using a
146 channel security mechanism such as TSIG or IPsec, or even to encrypt
147 them using IPsec, this would not be a very good solution for
148 interception attacks. First, this approach would impose a fairly
149 high processing cost per DNS message, as well as a very high cost
150 associated with establishing and maintaining bilateral trust
151 relationships between all the parties that might be involved in
152 resolving any particular query. For heavily used name servers (such
153 as the servers for the root zone), this cost would almost certainly
154 be prohibitively high. Even more important, however, is that the
155 underlying trust model in such a design would be wrong, since at best
156 it would only provide a hop-by-hop integrity check on DNS messages
157 and would not provide any sort of end-to-end integrity check between
158 the producer of DNS data (the zone administrator) and the consumer of
159 DNS data (the application that triggered the query).
161 By contrast, DNSSEC (when used properly) does provide an end-to-end
162 data integrity check, and is thus a much better solution for this
163 class of problems during basic DNS lookup operations.
170Atkins & Austein Informational [Page 3]
172RFC 3833 DNS Threat Analysis August 2004
175 TSIG does have its place in corners of the DNS protocol where there's
176 a specific trust relationship between a particular client and a
177 particular server, such as zone transfer, dynamic update, or a
178 resolver (stub or otherwise) that is not going to check all the
179 DNSSEC signatures itself.
181 Note that DNSSEC does not provide any protection against modification
182 of the DNS message header, so any properly paranoid resolver must:
184 - Perform all of the DNSSEC signature checking on its own,
186 - Use TSIG (or some equivalent mechanism) to ensure the integrity of
187 its communication with whatever name servers it chooses to trust,
190 - Resign itself to the possibility of being attacked via packet
191 interception (and via other techniques discussed below).
1932.2. ID Guessing and Query Prediction
195 Since DNS is for the most part used over UDP/IP, it is relatively
196 easy for an attacker to generate packets which will match the
197 transport protocol parameters. The ID field in the DNS header is
198 only a 16-bit field and the server UDP port associated with DNS is a
199 well-known value, so there are only 2**32 possible combinations of ID
200 and client UDP port for a given client and server. This is not a
201 particularly large range, and is not sufficient to protect against a
202 brute force search; furthermore, in practice both the client UDP port
203 and the ID can often be predicted from previous traffic, and it is
204 not uncommon for the client port to be a known fixed value as well
205 (due to firewalls or other restrictions), thus frequently reducing
206 the search space to a range smaller than 2**16.
208 By itself, ID guessing is not enough to allow an attacker to inject
209 bogus data, but combined with knowledge (or guesses) about QNAMEs and
210 QTYPEs for which a resolver might be querying, this leaves the
211 resolver only weakly defended against injection of bogus responses.
213 Since this attack relies on predicting a resolver's behavior, it's
214 most likely to be successful when the victim is in a known state,
215 whether because the victim rebooted recently, or because the victim's
216 behavior has been influenced by some other action by the attacker, or
217 because the victim is responding (in a predictable way) to some third
218 party action known to the attacker.
226Atkins & Austein Informational [Page 4]
228RFC 3833 DNS Threat Analysis August 2004
231 This attack is both more and less difficult for the attacker than the
232 simple interception attack described above: more difficult, because
233 the attack only works when the attacker guesses correctly; less
234 difficult, because the attacker doesn't need to be on a transit or
237 In most other respects, this attack is similar to a packet
238 interception attack. A resolver that checks DNSSEC signatures will
239 be able to detect the forged response; resolvers that do not perform
240 DNSSEC signature checking themselves should use TSIG or some
241 equivalent mechanism to ensure the integrity of their communication
242 with a recursive name server that does perform DNSSEC signature
247 Perhaps the most interesting class of DNS-specific threats are the
248 name chaining attacks. These are a subset of a larger class of
249 name-based attacks, sometimes called "cache poisoning" attacks. Most
250 name-based attacks can be partially mitigated by the long-standing
251 defense of checking RRs in response messages for relevance to the
252 original query, but such defenses do not catch name chaining attacks.
253 There are several variations on the basic attack, but what they all
254 have in common is that they all involve DNS RRs whose RDATA portion
255 (right hand side) includes a DNS name (or, in a few cases, something
256 that is not a DNS name but which directly maps to a DNS name). Any
257 such RR is, at least in principle, a hook that lets an attacker feed
258 bad data into a victim's cache, thus potentially subverting
259 subsequent decisions based on DNS names.
261 The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
262 because they can redirect a victim's query to a location of the
263 attacker's choosing. RRs like MX and SRV are somewhat less
264 dangerous, but in principle they can also be used to trigger further
265 lookups at a location of the attacker's choosing. Address RR types
266 such as A or AAAA don't have DNS names in their RDATA, but since the
267 IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
268 IPv4 and IPv6 addresses, these record types can also be used in a
269 name chaining attack.
271 The general form of a name chaining attack is something like this:
273 - Victim issues a query, perhaps at the instigation of the attacker
274 or some third party; in some cases the query itself may be
275 unrelated to the name under attack (that is, the attacker is just
276 using this query as a means to inject false information about some
282Atkins & Austein Informational [Page 5]
284RFC 3833 DNS Threat Analysis August 2004
287 - Attacker injects response, whether via packet interception, query
288 guessing, or by being a legitimate name server that's involved at
289 some point in the process of answering the query that the victim
292 - Attacker's response includes one or more RRs with DNS names in
293 their RDATA; depending on which particular form this attack takes,
294 the object may be to inject false data associated with those names
295 into the victim's cache via the Additional section of this
296 response, or may be to redirect the next stage of the query to a
297 server of the attacker's choosing (in order to inject more complex
298 lies into the victim's cache than will fit easily into a single
299 response, or in order to place the lies in the Authority or Answer
300 section of a response where they will have a better chance of
301 sneaking past a resolver's defenses).
303 Any attacker who can insert resource records into a victim's cache
304 can almost certainly do some kind of damage, so there are cache
305 poisoning attacks which are not name chaining attacks in the sense
306 discussed here. However, in the case of name chaining attacks, the
307 cause and effect relationship between the initial attack and the
308 eventual result may be significantly more complex than in the other
309 forms of cache poisoning, so name chaining attacks merit special
312 The common thread in all of the name chaining attacks is that
313 response messages allow the attacker to introduce arbitrary DNS names
314 of the attacker's choosing and provide further information that the
315 attacker claims is associated with those names; unless the victim has
316 better knowledge of the data associated with those names, the victim
317 is going to have a hard time defending against this class of attacks.
319 This class of attack is particularly insidious given that it's quite
320 easy for an attacker to provoke a victim into querying for a
321 particular name of the attacker's choosing, for example, by embedding
322 a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
323 to the victim. If the victim's mail reading program attempts to
324 follow such a link, the result will be a DNS query for a name chosen
327 DNSSEC should provide a good defense against most (all?) variations
328 on this class of attack. By checking signatures, a resolver can
329 determine whether the data associated with a name really was inserted
330 by the delegated authority for that portion of the DNS name space.
331 More precisely, a resolver can determine whether the entity that
332 injected the data had access to an allegedly secret key whose
338Atkins & Austein Informational [Page 6]
340RFC 3833 DNS Threat Analysis August 2004
343 corresponding public key appears at an expected location in the DNS
344 name space with an expected chain of parental signatures that start
345 with a public key of which the resolver has prior knowledge.
347 DNSSEC signatures do not cover glue records, so there's still a
348 possibility of a name chaining attack involving glue, but with DNSSEC
349 it is possible to detect the attack by temporarily accepting the glue
350 in order to fetch the signed authoritative version of the same data,
351 then checking the signatures on the authoritative version.
3532.4. Betrayal By Trusted Server
355 Another variation on the packet interception attack is the trusted
356 server that turns out not to be so trustworthy, whether by accident
357 or by intent. Many client machines are only configured with stub
358 resolvers, and use trusted servers to perform all of their DNS
359 queries on their behalf. In many cases the trusted server is
360 furnished by the user's ISP and advertised to the client via DHCP or
361 PPP options. Besides accidental betrayal of this trust relationship
362 (via server bugs, successful server break-ins, etc), the server
363 itself may be configured to give back answers that are not what the
364 user would expect, whether in an honest attempt to help the user or
365 to promote some other goal such as furthering a business partnership
366 between the ISP and some third party.
368 This problem is particularly acute for frequent travelers who carry
369 their own equipment and expect it to work in much the same way
370 wherever they go. Such travelers need trustworthy DNS service
371 without regard to who operates the network into which their equipment
372 is currently plugged or what brand of middle boxes the local
373 infrastructure might use.
375 While the obvious solution to this problem would be for the client to
376 choose a more trustworthy server, in practice this may not be an
377 option for the client. In many network environments a client machine
378 has only a limited set of recursive name servers from which to
379 choose, and none of them may be particularly trustworthy. In extreme
380 cases, port filtering or other forms of packet interception may
381 prevent the client host from being able to run an iterative resolver
382 even if the owner of the client machine is willing and able to do so.
383 Thus, while the initial source of this problem is not a DNS protocol
384 attack per se, this sort of betrayal is a threat to DNS clients, and
385 simply switching to a different recursive name server is not an
388 Viewed strictly from the DNS protocol standpoint, the only difference
389 between this sort of betrayal and a packet interception attack is
390 that in this case the client has voluntarily sent its request to the
394Atkins & Austein Informational [Page 7]
396RFC 3833 DNS Threat Analysis August 2004
399 attacker. The defense against this is the same as with a packet
400 interception attack: the resolver must either check DNSSEC signatures
401 itself or use TSIG (or equivalent) to authenticate the server that it
402 has chosen to trust. Note that use of TSIG does not by itself
403 guarantee that a name server is at all trustworthy: all TSIG can do
404 is help a resolver protect its communication with a name server that
405 it has already decided to trust for other reasons. Protecting a
406 resolver's communication with a server that's giving out bogus
407 answers is not particularly useful.
409 Also note that if the stub resolver does not trust the name server
410 that is doing work on its behalf and wants to check the DNSSEC
411 signatures itself, the resolver really does need to have independent
412 knowledge of the DNSSEC public key(s) it needs in order to perform
413 the check. Usually the public key for the root zone is enough, but
414 in some cases knowledge of additional keys may also be appropriate.
416 It is difficult to escape the conclusion that a properly paranoid
417 resolver must always perform its own signature checking, and that
418 this rule even applies to stub resolvers.
4202.5. Denial of Service
422 As with any network service (or, indeed, almost any service of any
423 kind in any domain of discourse), DNS is vulnerable to denial of
424 service attacks. DNSSEC does not help this, and may in fact make the
425 problem worse for resolvers that check signatures, since checking
426 signatures both increases the processing cost per DNS message and in
427 some cases can also increase the number of messages needed to answer
428 a query. TSIG (and similar mechanisms) have equivalent problems.
430 DNS servers are also at risk of being used as denial of service
431 amplifiers, since DNS response packets tend to be significantly
432 longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
4352.6. Authenticated Denial of Domain Names
437 Much discussion has taken place over the question of authenticated
438 denial of domain names. The particular question is whether there is
439 a requirement for authenticating the non-existence of a name. The
440 issue is whether the resolver should be able to detect when an
441 attacker removes RRs from a response.
443 General paranoia aside, the existence of RR types whose absence
444 causes an action other than immediate failure (such as missing MX and
445 SRV RRs, which fail over to A RRs) constitutes a real threat.
446 Arguably, in some cases, even the absence of an RR might be
450Atkins & Austein Informational [Page 8]
452RFC 3833 DNS Threat Analysis August 2004
455 considered a problem. The question remains: how serious is this
456 threat? Clearly the threat does exist; general paranoia says that
457 some day it'll be on the front page of some major newspaper, even if
458 we cannot conceive of a plausible scenario involving this attack
459 today. This implies that some mitigation of this risk is required.
461 Note that it's necessary to prove the non-existence of applicable
462 wildcard RRs as part of the authenticated denial mechanism, and that,
463 in a zone that is more than one label deep, such a proof may require
464 proving the non-existence of multiple discrete sets of wildcard RRs.
466 DNSSEC does include mechanisms which make it possible to determine
467 which authoritative names exist in a zone, and which authoritative
468 resource record types exist at those names. The DNSSEC protections
469 do not cover non-authoritative data such as glue records.
473 Much discussion has taken place over whether and how to provide data
474 integrity and data origin authentication for "wildcard" DNS names.
475 Conceptually, RRs with wildcard names are patterns for synthesizing
476 RRs on the fly according to the matching rules described in section
477 4.3.2 of RFC 1034. While the rules that control the behavior of
478 wildcard names have a few quirks that can make them a trap for the
479 unwary zone administrator, it's clear that a number of sites make
480 heavy use of wildcard RRs, particularly wildcard MX RRs.
482 In order to provide the desired services for wildcard RRs, we need to
485 - We need a way to attest to the existence of the wildcard RR itself
486 (that is, we need to show that the synthesis rule exists), and
488 - We need a way to attest to the non-existence of any RRs which, if
489 they existed, would make the wildcard RR irrelevant according to
490 the synthesis rules that govern the way in which wildcard RRs are
491 used (that is, we need to show that the synthesis rule is
494 Note that this makes the wildcard mechanisms dependent upon the
495 authenticated denial mechanism described in the previous section.
497 DNSSEC includes mechanisms along the lines described above, which
498 make it possible for a resolver to verify that a name server applied
499 the wildcard expansion rules correctly when generating an answer.
506Atkins & Austein Informational [Page 9]
508RFC 3833 DNS Threat Analysis August 2004
5113. Weaknesses of DNSSEC
513 DNSSEC has some problems of its own:
515 - DNSSEC is complex to implement and includes some nasty edge cases
516 at the zone cuts that require very careful coding. Testbed
517 experience to date suggests that trivial zone configuration errors
518 or expired keys can cause serious problems for a DNSSEC-aware
519 resolver, and that the current protocol's error reporting
520 capabilities may leave something to be desired.
522 - DNSSEC significantly increases the size of DNS response packets;
523 among other issues, this makes DNSSEC-aware DNS servers even more
524 effective as denial of service amplifiers.
526 - DNSSEC answer validation increases the resolver's work load, since
527 a DNSSEC-aware resolver will need to perform signature validation
528 and in some cases will also need to issue further queries. This
529 increased workload will also increase the time it takes to get an
530 answer back to the original DNS client, which is likely to trigger
531 both timeouts and re-queries in some cases. Arguably, many current
532 DNS clients are already too impatient even before taking the
533 further delays that DNSSEC will impose into account, but that topic
534 is beyond the scope of this note.
536 - Like DNS itself, DNSSEC's trust model is almost totally
537 hierarchical. While DNSSEC does allow resolvers to have special
538 additional knowledge of public keys beyond those for the root, in
539 the general case the root key is the one that matters. Thus any
540 compromise in any of the zones between the root and a particular
541 target name can damage DNSSEC's ability to protect the integrity of
542 data owned by that target name. This is not a change, since
543 insecure DNS has the same model.
545 - Key rollover at the root is really hard. Work to date has not even
546 come close to adequately specifying how the root key rolls over, or
547 even how it's configured in the first place.
549 - DNSSEC creates a requirement of loose time synchronization between
550 the validating resolver and the entity creating the DNSSEC
551 signatures. Prior to DNSSEC, all time-related actions in DNS could
552 be performed by a machine that only knew about "elapsed" or
553 "relative" time. Because the validity period of a DNSSEC signature
554 is based on "absolute" time, a validating resolver must have the
555 same concept of absolute time as the zone signer in order to
556 determine whether the signature is within its validity period or
557 has expired. An attacker that can change a resolver's opinion of
558 the current absolute time can fool the resolver using expired
562Atkins & Austein Informational [Page 10]
564RFC 3833 DNS Threat Analysis August 2004
567 signatures. An attacker that can change the zone signer's opinion
568 of the current absolute time can fool the zone signer into
569 generating signatures whose validity period does not match what the
572 - The possible existence of wildcard RRs in a zone complicates the
573 authenticated denial mechanism considerably. For most of the
574 decade that DNSSEC has been under development these issues were
575 poorly understood. At various times there have been questions as
576 to whether the authenticated denial mechanism is completely
577 airtight and whether it would be worthwhile to optimize the
578 authenticated denial mechanism for the common case in which
579 wildcards are not present in a zone. However, the main problem is
580 just the inherent complexity of the wildcard mechanism itself.
581 This complexity probably makes the code for generating and checking
582 authenticated denial attestations somewhat fragile, but since the
583 alternative of giving up wildcards entirely is not practical due to
584 widespread use, we are going to have to live with wildcards. The
585 question just becomes one of whether or not the proposed
586 optimizations would make DNSSEC's mechanisms more or less fragile.
588 - Even with DNSSEC, the class of attacks discussed in section 2.4 is
589 not easy to defeat. In order for DNSSEC to be effective in this
590 case, it must be possible to configure the resolver to expect
591 certain categories of DNS records to be signed. This may require
592 manual configuration of the resolver, especially during the initial
593 DNSSEC rollout period when the resolver cannot reasonably expect
594 the root and TLD zones to be signed.
5964. Topics for Future Work
598 This section lists a few subjects not covered above which probably
599 need additional study, additional mechanisms, or both.
6014.1. Interactions With Other Protocols
603 The above discussion has concentrated exclusively on attacks within
604 the boundaries of the DNS protocol itself, since those are (some of)
605 the problems against which DNSSEC was intended to protect. There
606 are, however, other potential problems at the boundaries where DNS
607 interacts with other protocols.
6094.2. Securing DNS Dynamic Update
611 DNS dynamic update opens a number of potential problems when combined
612 with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
613 authenticate the updating client to the server. While TSIG does not
614 scale very well (it requires manual configuration of shared keys
618Atkins & Austein Informational [Page 11]
620RFC 3833 DNS Threat Analysis August 2004
623 between the DNS name server and each TSIG client), it works well in a
624 limited or closed environment such as a DHCP server updating a local
627 Major issues arise when trying to use dynamic update on a secure
628 zone. TSIG can similarly be used in a limited fashion to
629 authenticate the client to the server, but TSIG only protects DNS
630 transactions, not the actual data, and the TSIG is not inserted into
631 the DNS zone, so resolvers cannot use the TSIG as a way of verifying
632 the changes to the zone. This means that either:
634 a) The updating client must have access to a zone-signing key in
635 order to sign the update before sending it to the server, or
637 b) The DNS name server must have access to an online zone-signing key
638 in order to sign the update.
640 In either case, a zone-signing key must be available to create signed
641 RRsets to place in the updated zone. The fact that this key must be
642 online (or at least available) is a potential security risk.
644 Dynamic update also requires an update to the SERIAL field of the
645 zone's SOA RR. In theory, this could also be handled via either of
646 the above options, but in practice (a) would almost certainly be
647 extremely fragile, so (b) is the only workable mechanism.
649 There are other threats in terms of describing the policy of who can
650 make what changes to which RRsets in the zone. The current access
651 control scheme in Secure Dynamic Update is fairly limited. There is
652 no way to give fine-grained access to updating DNS zone information
653 to multiple entities, each of whom may require different kinds of
654 access. For example, Alice may need to be able to add new nodes to
655 the zone or change existing nodes, but not remove them; Bob may need
656 to be able to remove zones but not add them; Carol may need to be
657 able to add, remove, or modify nodes, but only A records.
659 Scaling properties of the key management problem here are a
660 particular concern that needs more study.
6624.3. Securing DNS Zone Replication
664 As discussed in previous sections, DNSSEC per se attempts to provide
665 data integrity and data origin authentication services on top of the
666 normal DNS query protocol. Using the terminology discussed in
667 [RFC3552], DNSSEC provides "object security" for the normal DNS query
668 protocol. For purposes of replicating entire DNS zones, however,
669 DNSSEC does not provide object security, because zones include
670 unsigned NS RRs and glue at delegation points. Use of TSIG to
674Atkins & Austein Informational [Page 12]
676RFC 3833 DNS Threat Analysis August 2004
679 protect zone transfer (AXFR or IXFR) operations provides "channel
680 security", but still does not provide object security for complete
681 zones. The trust relationships involved in zone transfer are still
682 very much a hop-by-hop matter of name server operators trusting other
683 name server operators rather than an end-to-end matter of name server
684 operators trusting zone administrators.
686 Zone object security was not an explicit design goal of DNSSEC, so
687 failure to provide this service should not be a surprise.
688 Nevertheless, there are some zone replication scenarios for which
689 this would be a very useful additional service, so this seems like a
690 useful area for future work. In theory it should not be difficult to
691 add zone object security as a backwards compatible enhancement to the
692 existing DNSSEC model, but the DNSEXT WG has not yet discussed either
693 the desirability of or the requirements for such an enhancement.
697 Based on the above analysis, the DNSSEC extensions do appear to solve
698 a set of problems that do need to be solved, and are worth deploying.
700Security Considerations
702 This entire document is about security considerations of the DNS.
703 The authors believe that deploying DNSSEC will help to address some,
704 but not all, of the known threats to the DNS.
708 This note is based both on previous published works by others and on
709 a number of discussions both public and private over a period of many
710 years, but particular thanks go to
730Atkins & Austein Informational [Page 13]
732RFC 3833 DNS Threat Analysis August 2004
735 and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
736 groups whose names and contributions the authors have forgotten, none
737 of whom are responsible for what the authors did with their ideas.
739 As with any work of this nature, the authors of this note acknowledge
740 that we are standing on the toes of those who have gone before us.
741 Readers interested in this subject may also wish to read
742 [Bellovin95], [Schuba93], and [Vixie95].
746 [RFC1034] Mockapetris, P., "Domain names - concepts and
747 facilities", STD 13, RFC 1034, November 1987.
749 [RFC1035] Mockapetris, P., "Domain names - implementation and
750 specification", STD 13, RFC 1035, November 1987.
752 [RFC1123] Braden, R., "Requirements for Internet Hosts -
753 Application and Support", STD 3, RFC 1123, October 1989.
755 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
756 Specification", RFC 2181, July 1997.
758 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
759 NCACHE)", RFC 2308, March 1998.
761 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
764 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
765 Wellington, "Secret Key Transaction Authentication for
766 DNS (TSIG)", RFC 2845, May 2000.
768 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
769 (TKEY RR)", RFC 2930, September 2000.
771 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
772 Update", RFC 3007, November 2000.
774 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
775 Extensions", RFC 2535, March 1999.
786Atkins & Austein Informational [Page 14]
788RFC 3833 DNS Threat Analysis August 2004
791Informative References
793 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
794 Text on Security Considerations", BCP 72, RFC 3552, July
797 [Bellovin95] Bellovin, S., "Using the Domain Name System for System
798 Break-Ins", Proceedings of the Fifth Usenix Unix
799 Security Symposium, June 1995.
801 [Galvin93] Design team meeting summary message posted to dns-
802 security@tis.com mailing list by Jim Galvin on 19
805 [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
806 System Protocol", Master's thesis, Purdue University
807 Department of Computer Sciences, August 1993.
809 [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
810 the Fifth Usenix Unix Security Symposium, June 1995.
815 IHTFP Consulting, Inc.
820 EMail: derek@ihtfp.com
824 Internet Systems Consortium
826 Redwood City, CA 94063
842Atkins & Austein Informational [Page 15]
844RFC 3833 DNS Threat Analysis August 2004
847Full Copyright Statement
849 Copyright (C) The Internet Society (2004). This document is subject
850 to the rights, licenses and restrictions contained in BCP 78, and
851 except as set forth therein, the authors retain all their rights.
853 This document and the information contained herein are provided on an
854 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
855 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
856 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
857 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
858 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
859 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
863 The IETF takes no position regarding the validity or scope of any
864 Intellectual Property Rights or other rights that might be claimed to
865 pertain to the implementation or use of the technology described in
866 this document or the extent to which any license under such rights
867 might or might not be available; nor does it represent that it has
868 made any independent effort to identify any such rights. Information
869 on the procedures with respect to rights in RFC documents can be
870 found in BCP 78 and BCP 79.
872 Copies of IPR disclosures made to the IETF Secretariat and any
873 assurances of licenses to be made available, or the result of an
874 attempt made to obtain a general license or permission for the use of
875 such proprietary rights by implementers or users of this
876 specification can be obtained from the IETF on-line IPR repository at
877 http://www.ietf.org/ipr.
879 The IETF invites any interested party to bring to its attention any
880 copyrights, patents or patent applications, or other proprietary
881 rights that may cover technology that may be required to implement
882 this standard. Please address the information to the IETF at ietf-
887 Funding for the RFC Editor function is currently provided by the
898Atkins & Austein Informational [Page 16]