rfc3833.txt

bind 源码 最新实现 linux/unix/windows平台

     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.