rfc3833.txt

bind 9.3结合mysql数据库

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