diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3833.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3833.txt | 899 |
1 files changed, 0 insertions, 899 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3833.txt b/contrib/bind9/doc/rfc/rfc3833.txt deleted file mode 100644 index 8ce4d34..0000000 --- a/contrib/bind9/doc/rfc/rfc3833.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Atkins -Request for Comments: 3833 IHTFP Consulting -Category: Informational R. Austein - ISC - August 2004 - - - Threat Analysis of the Domain Name System (DNS) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - Although the DNS Security Extensions (DNSSEC) have been under - development for most of the last decade, the IETF has never written - down the specific set of threats against which DNSSEC is designed to - protect. Among other drawbacks, this cart-before-the-horse situation - has made it difficult to determine whether DNSSEC meets its design - goals, since its design goals are not well specified. This note - attempts to document some of the known threats to the DNS, and, in - doing so, attempts to measure to what extent (if any) DNSSEC is a - useful tool in defending against these threats. - -1. Introduction - - The earliest organized work on DNSSEC within the IETF was an open - design team meeting organized by members of the DNS working group in - November 1993 at the 28th IETF meeting in Houston. The broad - outlines of DNSSEC as we know it today are already clear in Jim - Galvin's summary of the results of that meeting [Galvin93]: - - - While some participants in the meeting were interested in - protecting against disclosure of DNS data to unauthorized parties, - the design team made an explicit decision that "DNS data is - `public'", and ruled all threats of data disclosure explicitly out - of scope for DNSSEC. - - - While some participants in the meeting were interested in - authentication of DNS clients and servers as a basis for access - control, this work was also ruled out of scope for DNSSEC per se. - - - -Atkins & Austein Informational [Page 1] - -RFC 3833 DNS Threat Analysis August 2004 - - - - Backwards compatibility and co-existence with "insecure DNS" was - listed as an explicit requirement. - - - The resulting list of desired security services was - 1) data integrity, and - 2) data origin authentication. - - - The design team noted that a digital signature mechanism would - support the desired services. - - While a number of detail decisions were yet to be made (and in some - cases remade after implementation experience) over the subsequent - decade, the basic model and design goals have remained fixed. - - Nowhere, however, does any of the DNSSEC work attempt to specify in - any detail the sorts of attacks against which DNSSEC is intended to - protect, or the reasons behind the list of desired security services - that came out of the Houston meeting. For that, we have to go back - to a paper originally written by Steve Bellovin in 1990 but not - published until 1995, for reasons that Bellovin explained in the - paper's epilogue [Bellovin95]. - - While it may seem a bit strange to publish the threat analysis a - decade after starting work on the protocol designed to defend against - it, that is, nevertheless, what this note attempts to do. Better - late than never. - - This note assumes that the reader is familiar with both the DNS and - with DNSSEC, and does not attempt to provide a tutorial on either. - The DNS documents most relevant to the subject of this note are: - [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], - [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. - - For purposes of discussion, this note uses the term "DNSSEC" to refer - to the core hierarchical public key and signature mechanism specified - in the DNSSEC documents, and refers to TKEY and TSIG as separate - mechanisms, even though channel security mechanisms such as TKEY and - TSIG are also part of the larger problem of "securing DNS" and thus - are often considered part of the overall set of "DNS security - extensions". This is an arbitrary distinction that in part reflects - the way in which the protocol has evolved (introduction of a - putatively simpler channel security model for certain operations such - as zone transfers and dynamic update requests), and perhaps should be - changed in a future revision of this note. - - - - - - - -Atkins & Austein Informational [Page 2] - -RFC 3833 DNS Threat Analysis August 2004 - - -2. Known Threats - - There are several distinct classes of threats to the DNS, most of - which are DNS-related instances of more general problems, but a few - of which are specific to peculiarities of the DNS protocol. - -2.1. Packet Interception - - Some of the simplest threats against DNS are various forms of packet - interception: monkey-in-the-middle attacks, eavesdropping on requests - combined with spoofed responses that beat the real response back to - the resolver, and so forth. In any of these scenarios, the attacker - can simply tell either party (usually the resolver) whatever it wants - that party to believe. While packet interception attacks are far - from unique to DNS, DNS's usual behavior of sending an entire query - or response in a single unsigned, unencrypted UDP packet makes these - attacks particularly easy for any bad guy with the ability to - intercept packets on a shared or transit network. - - To further complicate things, the DNS query the attacker intercepts - may just be a means to an end for the attacker: the attacker might - even choose to return the correct result in the answer section of a - reply message while using other parts of the message to set the stage - for something more complicated, for example, a name chaining attack - (see section 2.3). - - While it certainly would be possible to sign DNS messages using a - channel security mechanism such as TSIG or IPsec, or even to encrypt - them using IPsec, this would not be a very good solution for - interception attacks. First, this approach would impose a fairly - high processing cost per DNS message, as well as a very high cost - associated with establishing and maintaining bilateral trust - relationships between all the parties that might be involved in - resolving any particular query. For heavily used name servers (such - as the servers for the root zone), this cost would almost certainly - be prohibitively high. Even more important, however, is that the - underlying trust model in such a design would be wrong, since at best - it would only provide a hop-by-hop integrity check on DNS messages - and would not provide any sort of end-to-end integrity check between - the producer of DNS data (the zone administrator) and the consumer of - DNS data (the application that triggered the query). - - By contrast, DNSSEC (when used properly) does provide an end-to-end - data integrity check, and is thus a much better solution for this - class of problems during basic DNS lookup operations. - - - - - - -Atkins & Austein Informational [Page 3] - -RFC 3833 DNS Threat Analysis August 2004 - - - TSIG does have its place in corners of the DNS protocol where there's - a specific trust relationship between a particular client and a - particular server, such as zone transfer, dynamic update, or a - resolver (stub or otherwise) that is not going to check all the - DNSSEC signatures itself. - - Note that DNSSEC does not provide any protection against modification - of the DNS message header, so any properly paranoid resolver must: - - - Perform all of the DNSSEC signature checking on its own, - - - Use TSIG (or some equivalent mechanism) to ensure the integrity of - its communication with whatever name servers it chooses to trust, - or - - - Resign itself to the possibility of being attacked via packet - interception (and via other techniques discussed below). - -2.2. ID Guessing and Query Prediction - - Since DNS is for the most part used over UDP/IP, it is relatively - easy for an attacker to generate packets which will match the - transport protocol parameters. The ID field in the DNS header is - only a 16-bit field and the server UDP port associated with DNS is a - well-known value, so there are only 2**32 possible combinations of ID - and client UDP port for a given client and server. This is not a - particularly large range, and is not sufficient to protect against a - brute force search; furthermore, in practice both the client UDP port - and the ID can often be predicted from previous traffic, and it is - not uncommon for the client port to be a known fixed value as well - (due to firewalls or other restrictions), thus frequently reducing - the search space to a range smaller than 2**16. - - By itself, ID guessing is not enough to allow an attacker to inject - bogus data, but combined with knowledge (or guesses) about QNAMEs and - QTYPEs for which a resolver might be querying, this leaves the - resolver only weakly defended against injection of bogus responses. - - Since this attack relies on predicting a resolver's behavior, it's - most likely to be successful when the victim is in a known state, - whether because the victim rebooted recently, or because the victim's - behavior has been influenced by some other action by the attacker, or - because the victim is responding (in a predictable way) to some third - party action known to the attacker. - - - - - - - -Atkins & Austein Informational [Page 4] - -RFC 3833 DNS Threat Analysis August 2004 - - - This attack is both more and less difficult for the attacker than the - simple interception attack described above: more difficult, because - the attack only works when the attacker guesses correctly; less - difficult, because the attacker doesn't need to be on a transit or - shared network. - - In most other respects, this attack is similar to a packet - interception attack. A resolver that checks DNSSEC signatures will - be able to detect the forged response; resolvers that do not perform - DNSSEC signature checking themselves should use TSIG or some - equivalent mechanism to ensure the integrity of their communication - with a recursive name server that does perform DNSSEC signature - checking. - -2.3. Name Chaining - - Perhaps the most interesting class of DNS-specific threats are the - name chaining attacks. These are a subset of a larger class of - name-based attacks, sometimes called "cache poisoning" attacks. Most - name-based attacks can be partially mitigated by the long-standing - defense of checking RRs in response messages for relevance to the - original query, but such defenses do not catch name chaining attacks. - There are several variations on the basic attack, but what they all - have in common is that they all involve DNS RRs whose RDATA portion - (right hand side) includes a DNS name (or, in a few cases, something - that is not a DNS name but which directly maps to a DNS name). Any - such RR is, at least in principle, a hook that lets an attacker feed - bad data into a victim's cache, thus potentially subverting - subsequent decisions based on DNS names. - - The worst examples in this class of RRs are CNAME, NS, and DNAME RRs - because they can redirect a victim's query to a location of the - attacker's choosing. RRs like MX and SRV are somewhat less - dangerous, but in principle they can also be used to trigger further - lookups at a location of the attacker's choosing. Address RR types - such as A or AAAA don't have DNS names in their RDATA, but since the - IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of - IPv4 and IPv6 addresses, these record types can also be used in a - name chaining attack. - - The general form of a name chaining attack is something like this: - - - Victim issues a query, perhaps at the instigation of the attacker - or some third party; in some cases the query itself may be - unrelated to the name under attack (that is, the attacker is just - using this query as a means to inject false information about some - other name). - - - - -Atkins & Austein Informational [Page 5] - -RFC 3833 DNS Threat Analysis August 2004 - - - - Attacker injects response, whether via packet interception, query - guessing, or by being a legitimate name server that's involved at - some point in the process of answering the query that the victim - issued. - - - Attacker's response includes one or more RRs with DNS names in - their RDATA; depending on which particular form this attack takes, - the object may be to inject false data associated with those names - into the victim's cache via the Additional section of this - response, or may be to redirect the next stage of the query to a - server of the attacker's choosing (in order to inject more complex - lies into the victim's cache than will fit easily into a single - response, or in order to place the lies in the Authority or Answer - section of a response where they will have a better chance of - sneaking past a resolver's defenses). - - Any attacker who can insert resource records into a victim's cache - can almost certainly do some kind of damage, so there are cache - poisoning attacks which are not name chaining attacks in the sense - discussed here. However, in the case of name chaining attacks, the - cause and effect relationship between the initial attack and the - eventual result may be significantly more complex than in the other - forms of cache poisoning, so name chaining attacks merit special - attention. - - The common thread in all of the name chaining attacks is that - response messages allow the attacker to introduce arbitrary DNS names - of the attacker's choosing and provide further information that the - attacker claims is associated with those names; unless the victim has - better knowledge of the data associated with those names, the victim - is going to have a hard time defending against this class of attacks. - - This class of attack is particularly insidious given that it's quite - easy for an attacker to provoke a victim into querying for a - particular name of the attacker's choosing, for example, by embedding - a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail - to the victim. If the victim's mail reading program attempts to - follow such a link, the result will be a DNS query for a name chosen - by the attacker. - - DNSSEC should provide a good defense against most (all?) variations - on this class of attack. By checking signatures, a resolver can - determine whether the data associated with a name really was inserted - by the delegated authority for that portion of the DNS name space. - More precisely, a resolver can determine whether the entity that - injected the data had access to an allegedly secret key whose - - - - - -Atkins & Austein Informational [Page 6] - -RFC 3833 DNS Threat Analysis August 2004 - - - corresponding public key appears at an expected location in the DNS - name space with an expected chain of parental signatures that start - with a public key of which the resolver has prior knowledge. - - DNSSEC signatures do not cover glue records, so there's still a - possibility of a name chaining attack involving glue, but with DNSSEC - it is possible to detect the attack by temporarily accepting the glue - in order to fetch the signed authoritative version of the same data, - then checking the signatures on the authoritative version. - -2.4. Betrayal By Trusted Server - - Another variation on the packet interception attack is the trusted - server that turns out not to be so trustworthy, whether by accident - or by intent. Many client machines are only configured with stub - resolvers, and use trusted servers to perform all of their DNS - queries on their behalf. In many cases the trusted server is - furnished by the user's ISP and advertised to the client via DHCP or - PPP options. Besides accidental betrayal of this trust relationship - (via server bugs, successful server break-ins, etc), the server - itself may be configured to give back answers that are not what the - user would expect, whether in an honest attempt to help the user or - to promote some other goal such as furthering a business partnership - between the ISP and some third party. - - This problem is particularly acute for frequent travelers who carry - their own equipment and expect it to work in much the same way - wherever they go. Such travelers need trustworthy DNS service - without regard to who operates the network into which their equipment - is currently plugged or what brand of middle boxes the local - infrastructure might use. - - While the obvious solution to this problem would be for the client to - choose a more trustworthy server, in practice this may not be an - option for the client. In many network environments a client machine - has only a limited set of recursive name servers from which to - choose, and none of them may be particularly trustworthy. In extreme - cases, port filtering or other forms of packet interception may - prevent the client host from being able to run an iterative resolver - even if the owner of the client machine is willing and able to do so. - Thus, while the initial source of this problem is not a DNS protocol - attack per se, this sort of betrayal is a threat to DNS clients, and - simply switching to a different recursive name server is not an - adequate defense. - - Viewed strictly from the DNS protocol standpoint, the only difference - between this sort of betrayal and a packet interception attack is - that in this case the client has voluntarily sent its request to the - - - -Atkins & Austein Informational [Page 7] - -RFC 3833 DNS Threat Analysis August 2004 - - - attacker. The defense against this is the same as with a packet - interception attack: the resolver must either check DNSSEC signatures - itself or use TSIG (or equivalent) to authenticate the server that it - has chosen to trust. Note that use of TSIG does not by itself - guarantee that a name server is at all trustworthy: all TSIG can do - is help a resolver protect its communication with a name server that - it has already decided to trust for other reasons. Protecting a - resolver's communication with a server that's giving out bogus - answers is not particularly useful. - - Also note that if the stub resolver does not trust the name server - that is doing work on its behalf and wants to check the DNSSEC - signatures itself, the resolver really does need to have independent - knowledge of the DNSSEC public key(s) it needs in order to perform - the check. Usually the public key for the root zone is enough, but - in some cases knowledge of additional keys may also be appropriate. - - It is difficult to escape the conclusion that a properly paranoid - resolver must always perform its own signature checking, and that - this rule even applies to stub resolvers. - -2.5. Denial of Service - - As with any network service (or, indeed, almost any service of any - kind in any domain of discourse), DNS is vulnerable to denial of - service attacks. DNSSEC does not help this, and may in fact make the - problem worse for resolvers that check signatures, since checking - signatures both increases the processing cost per DNS message and in - some cases can also increase the number of messages needed to answer - a query. TSIG (and similar mechanisms) have equivalent problems. - - DNS servers are also at risk of being used as denial of service - amplifiers, since DNS response packets tend to be significantly - longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help - here either. - -2.6. Authenticated Denial of Domain Names - - Much discussion has taken place over the question of authenticated - denial of domain names. The particular question is whether there is - a requirement for authenticating the non-existence of a name. The - issue is whether the resolver should be able to detect when an - attacker removes RRs from a response. - - General paranoia aside, the existence of RR types whose absence - causes an action other than immediate failure (such as missing MX and - SRV RRs, which fail over to A RRs) constitutes a real threat. - Arguably, in some cases, even the absence of an RR might be - - - -Atkins & Austein Informational [Page 8] - -RFC 3833 DNS Threat Analysis August 2004 - - - considered a problem. The question remains: how serious is this - threat? Clearly the threat does exist; general paranoia says that - some day it'll be on the front page of some major newspaper, even if - we cannot conceive of a plausible scenario involving this attack - today. This implies that some mitigation of this risk is required. - - Note that it's necessary to prove the non-existence of applicable - wildcard RRs as part of the authenticated denial mechanism, and that, - in a zone that is more than one label deep, such a proof may require - proving the non-existence of multiple discrete sets of wildcard RRs. - - DNSSEC does include mechanisms which make it possible to determine - which authoritative names exist in a zone, and which authoritative - resource record types exist at those names. The DNSSEC protections - do not cover non-authoritative data such as glue records. - -2.7. Wildcards - - Much discussion has taken place over whether and how to provide data - integrity and data origin authentication for "wildcard" DNS names. - Conceptually, RRs with wildcard names are patterns for synthesizing - RRs on the fly according to the matching rules described in section - 4.3.2 of RFC 1034. While the rules that control the behavior of - wildcard names have a few quirks that can make them a trap for the - unwary zone administrator, it's clear that a number of sites make - heavy use of wildcard RRs, particularly wildcard MX RRs. - - In order to provide the desired services for wildcard RRs, we need to - do two things: - - - We need a way to attest to the existence of the wildcard RR itself - (that is, we need to show that the synthesis rule exists), and - - - We need a way to attest to the non-existence of any RRs which, if - they existed, would make the wildcard RR irrelevant according to - the synthesis rules that govern the way in which wildcard RRs are - used (that is, we need to show that the synthesis rule is - applicable). - - Note that this makes the wildcard mechanisms dependent upon the - authenticated denial mechanism described in the previous section. - - DNSSEC includes mechanisms along the lines described above, which - make it possible for a resolver to verify that a name server applied - the wildcard expansion rules correctly when generating an answer. - - - - - - -Atkins & Austein Informational [Page 9] - -RFC 3833 DNS Threat Analysis August 2004 - - -3. Weaknesses of DNSSEC - - DNSSEC has some problems of its own: - - - DNSSEC is complex to implement and includes some nasty edge cases - at the zone cuts that require very careful coding. Testbed - experience to date suggests that trivial zone configuration errors - or expired keys can cause serious problems for a DNSSEC-aware - resolver, and that the current protocol's error reporting - capabilities may leave something to be desired. - - - DNSSEC significantly increases the size of DNS response packets; - among other issues, this makes DNSSEC-aware DNS servers even more - effective as denial of service amplifiers. - - - DNSSEC answer validation increases the resolver's work load, since - a DNSSEC-aware resolver will need to perform signature validation - and in some cases will also need to issue further queries. This - increased workload will also increase the time it takes to get an - answer back to the original DNS client, which is likely to trigger - both timeouts and re-queries in some cases. Arguably, many current - DNS clients are already too impatient even before taking the - further delays that DNSSEC will impose into account, but that topic - is beyond the scope of this note. - - - Like DNS itself, DNSSEC's trust model is almost totally - hierarchical. While DNSSEC does allow resolvers to have special - additional knowledge of public keys beyond those for the root, in - the general case the root key is the one that matters. Thus any - compromise in any of the zones between the root and a particular - target name can damage DNSSEC's ability to protect the integrity of - data owned by that target name. This is not a change, since - insecure DNS has the same model. - - - Key rollover at the root is really hard. Work to date has not even - come close to adequately specifying how the root key rolls over, or - even how it's configured in the first place. - - - DNSSEC creates a requirement of loose time synchronization between - the validating resolver and the entity creating the DNSSEC - signatures. Prior to DNSSEC, all time-related actions in DNS could - be performed by a machine that only knew about "elapsed" or - "relative" time. Because the validity period of a DNSSEC signature - is based on "absolute" time, a validating resolver must have the - same concept of absolute time as the zone signer in order to - determine whether the signature is within its validity period or - has expired. An attacker that can change a resolver's opinion of - the current absolute time can fool the resolver using expired - - - -Atkins & Austein Informational [Page 10] - -RFC 3833 DNS Threat Analysis August 2004 - - - signatures. An attacker that can change the zone signer's opinion - of the current absolute time can fool the zone signer into - generating signatures whose validity period does not match what the - signer intended. - - - The possible existence of wildcard RRs in a zone complicates the - authenticated denial mechanism considerably. For most of the - decade that DNSSEC has been under development these issues were - poorly understood. At various times there have been questions as - to whether the authenticated denial mechanism is completely - airtight and whether it would be worthwhile to optimize the - authenticated denial mechanism for the common case in which - wildcards are not present in a zone. However, the main problem is - just the inherent complexity of the wildcard mechanism itself. - This complexity probably makes the code for generating and checking - authenticated denial attestations somewhat fragile, but since the - alternative of giving up wildcards entirely is not practical due to - widespread use, we are going to have to live with wildcards. The - question just becomes one of whether or not the proposed - optimizations would make DNSSEC's mechanisms more or less fragile. - - - Even with DNSSEC, the class of attacks discussed in section 2.4 is - not easy to defeat. In order for DNSSEC to be effective in this - case, it must be possible to configure the resolver to expect - certain categories of DNS records to be signed. This may require - manual configuration of the resolver, especially during the initial - DNSSEC rollout period when the resolver cannot reasonably expect - the root and TLD zones to be signed. - -4. Topics for Future Work - - This section lists a few subjects not covered above which probably - need additional study, additional mechanisms, or both. - -4.1. Interactions With Other Protocols - - The above discussion has concentrated exclusively on attacks within - the boundaries of the DNS protocol itself, since those are (some of) - the problems against which DNSSEC was intended to protect. There - are, however, other potential problems at the boundaries where DNS - interacts with other protocols. - -4.2. Securing DNS Dynamic Update - - DNS dynamic update opens a number of potential problems when combined - with DNSSEC. Dynamic update of a non-secure zone can use TSIG to - authenticate the updating client to the server. While TSIG does not - scale very well (it requires manual configuration of shared keys - - - -Atkins & Austein Informational [Page 11] - -RFC 3833 DNS Threat Analysis August 2004 - - - between the DNS name server and each TSIG client), it works well in a - limited or closed environment such as a DHCP server updating a local - DNS name server. - - Major issues arise when trying to use dynamic update on a secure - zone. TSIG can similarly be used in a limited fashion to - authenticate the client to the server, but TSIG only protects DNS - transactions, not the actual data, and the TSIG is not inserted into - the DNS zone, so resolvers cannot use the TSIG as a way of verifying - the changes to the zone. This means that either: - - a) The updating client must have access to a zone-signing key in - order to sign the update before sending it to the server, or - - b) The DNS name server must have access to an online zone-signing key - in order to sign the update. - - In either case, a zone-signing key must be available to create signed - RRsets to place in the updated zone. The fact that this key must be - online (or at least available) is a potential security risk. - - Dynamic update also requires an update to the SERIAL field of the - zone's SOA RR. In theory, this could also be handled via either of - the above options, but in practice (a) would almost certainly be - extremely fragile, so (b) is the only workable mechanism. - - There are other threats in terms of describing the policy of who can - make what changes to which RRsets in the zone. The current access - control scheme in Secure Dynamic Update is fairly limited. There is - no way to give fine-grained access to updating DNS zone information - to multiple entities, each of whom may require different kinds of - access. For example, Alice may need to be able to add new nodes to - the zone or change existing nodes, but not remove them; Bob may need - to be able to remove zones but not add them; Carol may need to be - able to add, remove, or modify nodes, but only A records. - - Scaling properties of the key management problem here are a - particular concern that needs more study. - -4.3. Securing DNS Zone Replication - - As discussed in previous sections, DNSSEC per se attempts to provide - data integrity and data origin authentication services on top of the - normal DNS query protocol. Using the terminology discussed in - [RFC3552], DNSSEC provides "object security" for the normal DNS query - protocol. For purposes of replicating entire DNS zones, however, - DNSSEC does not provide object security, because zones include - unsigned NS RRs and glue at delegation points. Use of TSIG to - - - -Atkins & Austein Informational [Page 12] - -RFC 3833 DNS Threat Analysis August 2004 - - - protect zone transfer (AXFR or IXFR) operations provides "channel - security", but still does not provide object security for complete - zones. The trust relationships involved in zone transfer are still - very much a hop-by-hop matter of name server operators trusting other - name server operators rather than an end-to-end matter of name server - operators trusting zone administrators. - - Zone object security was not an explicit design goal of DNSSEC, so - failure to provide this service should not be a surprise. - Nevertheless, there are some zone replication scenarios for which - this would be a very useful additional service, so this seems like a - useful area for future work. In theory it should not be difficult to - add zone object security as a backwards compatible enhancement to the - existing DNSSEC model, but the DNSEXT WG has not yet discussed either - the desirability of or the requirements for such an enhancement. - -5. Conclusion - - Based on the above analysis, the DNSSEC extensions do appear to solve - a set of problems that do need to be solved, and are worth deploying. - -Security Considerations - - This entire document is about security considerations of the DNS. - The authors believe that deploying DNSSEC will help to address some, - but not all, of the known threats to the DNS. - -Acknowledgments - - This note is based both on previous published works by others and on - a number of discussions both public and private over a period of many - years, but particular thanks go to - - Jaap Akkerhuis, - Steve Bellovin, - Dan Bernstein, - Randy Bush, - Steve Crocker, - Olafur Gudmundsson, - Russ Housley, - Rip Loomis, - Allison Mankin, - Paul Mockapetris, - Thomas Narten - Mans Nilsson, - Pekka Savola, - Paul Vixie, - Xunhua Wang, - - - -Atkins & Austein Informational [Page 13] - -RFC 3833 DNS Threat Analysis August 2004 - - - and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working - groups whose names and contributions the authors have forgotten, none - of whom are responsible for what the authors did with their ideas. - - As with any work of this nature, the authors of this note acknowledge - that we are standing on the toes of those who have gone before us. - Readers interested in this subject may also wish to read - [Bellovin95], [Schuba93], and [Vixie95]. - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS - (TKEY RR)", RFC 2930, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, March 1999. - - - - - - - - - - -Atkins & Austein Informational [Page 14] - -RFC 3833 DNS Threat Analysis August 2004 - - -Informative References - - [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, July - 2003. - - [Bellovin95] Bellovin, S., "Using the Domain Name System for System - Break-Ins", Proceedings of the Fifth Usenix Unix - Security Symposium, June 1995. - - [Galvin93] Design team meeting summary message posted to dns- - security@tis.com mailing list by Jim Galvin on 19 - November 1993. - - [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name - System Protocol", Master's thesis, Purdue University - Department of Computer Sciences, August 1993. - - [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of - the Fifth Usenix Unix Security Symposium, June 1995. - -Authors' Addresses - - Derek Atkins - IHTFP Consulting, Inc. - 6 Farragut Ave - Somerville, MA 02144 - USA - - EMail: derek@ihtfp.com - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - - - - - - - - - - -Atkins & Austein Informational [Page 15] - -RFC 3833 DNS Threat Analysis August 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Atkins & Austein Informational [Page 16] - |
