draft-ietf-dnsop-bad-dns-res-04.txt

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

DNS Operations                                                 M. Larson
Internet-Draft                                                 P. Barber
Expires: January 18, 2006                                       VeriSign
                                                           July 17, 2005


                  Observed DNS Resolution Misbehavior
                    draft-ietf-dnsop-bad-dns-res-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes DNS iterative resolver behavior that results in a
   significant query volume sent to the root and top-level domain (TLD)
   name servers.  We offer implementation advice to iterative resolver
   developers to alleviate these unnecessary queries.  The
   recommendations made in this document are a direct byproduct of
   observation and analysis of abnormal query traffic patterns seen at
   two of the thirteen root name servers and all thirteen com/net TLD
   name servers.



Larson & Barber         Expires January 18, 2006                [Page 1]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  A note about terminology in this memo  . . . . . . . . . .   3
   2.   Observed iterative resolver misbehavior  . . . . . . . . . .   5
     2.1  Aggressive requerying for delegation information . . . . .   5
       2.1.1  Recommendation . . . . . . . . . . . . . . . . . . . .   6
     2.2  Repeated queries to lame servers . . . . . . . . . . . . .   7
       2.2.1  Recommendation . . . . . . . . . . . . . . . . . . . .   7
     2.3  Inability to follow multiple levels of indirection . . . .   8
       2.3.1  Recommendation . . . . . . . . . . . . . . . . . . . .   9
     2.4  Aggressive retransmission when fetching glue . . . . . . .   9
       2.4.1  Recommendation . . . . . . . . . . . . . . . . . . . .  10
     2.5  Aggressive retransmission behind firewalls . . . . . . . .  10
       2.5.1  Recommendation . . . . . . . . . . . . . . . . . . . .  11
     2.6  Misconfigured NS records . . . . . . . . . . . . . . . . .  11
       2.6.1  Recommendation . . . . . . . . . . . . . . . . . . . .  12
     2.7  Name server records with zero TTL  . . . . . . . . . . . .  12
       2.7.1  Recommendation . . . . . . . . . . . . . . . . . . . .  13
     2.8  Unnecessary dynamic update messages  . . . . . . . . . . .  13
       2.8.1  Recommendation . . . . . . . . . . . . . . . . . . . .  14
     2.9  Queries for domain names resembling IPv4 addresses . . . .  14
       2.9.1  Recommendation . . . . . . . . . . . . . . . . . . . .  14
     2.10   Misdirected recursive queries  . . . . . . . . . . . . .  15
       2.10.1   Recommendation . . . . . . . . . . . . . . . . . . .  15
     2.11   Suboptimal name server selection algorithm . . . . . . .  15
       2.11.1   Recommendation . . . . . . . . . . . . . . . . . . .  16
   3.   IANA considerations  . . . . . . . . . . . . . . . . . . . .  17
   4.   Security considerations  . . . . . . . . . . . . . . . . . .  18
   5.   Internationalization considerations  . . . . . . . . . . . .  19
   6.   Informative References . . . . . . . . . . . . . . . . . . .  19
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  21














Larson & Barber         Expires January 18, 2006                [Page 2]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


1.  Introduction

   Observation of query traffic received by two root name servers and
   the thirteen com/net TLD name servers has revealed that a large
   proportion of the total traffic often consists of "requeries".  A
   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
   repeatedly at an unexpectedly high rate.  We have observed requeries
   from both a single IP address and multiple IP addresses (i.e., the
   same query received simultaneously from multiple IP addresses).

   By analyzing requery events we have found that the cause of the
   duplicate traffic is almost always a deficient iterative resolver,
   stub resolver or application implementation combined with an
   operational anomaly.  The implementation deficiencies we have
   identified to date include well-intentioned recovery attempts gone
   awry, insufficient caching of failures, early abort when multiple
   levels of indirection must be followed, and aggressive retry by stub
   resolvers or applications.  Anomalies that we have seen trigger
   requery events include lame delegations, unusual glue records, and
   anything that makes all authoritative name servers for a zone
   unreachable (DoS attacks, crashes, maintenance, routing failures,
   congestion, etc.).

   In the following sections, we provide a detailed explanation of the
   observed behavior and recommend changes that will reduce the requery
   rate.  None of the changes recommended affects the core DNS protocol
   specification; instead, this document consists of guidelines to
   implementors of iterative resolvers.

1.1  A note about terminology in this memo

   To recast an old saying about standards, the nice thing about DNS
   terms is that there are so many of them to choose from.  Writing or
   talking about DNS can be difficult and cause confusion resulting from
   a lack of agreed-upon terms for its various components.  Further
   complicating matters are implementations that combine multiple roles
   into one piece of software, which makes naming the result
   problematic.  An example is the entity that accepts recursive
   queries, issues iterative queries as necessary to resolve the initial
   recursive query, caches responses it receives, and which is also able
   to answer questions about certain zones authoritatively.  This entity
   is an iterative resolver combined with an authoritative name server
   and is often called a "recursive name server" or a "caching name
   server".

   This memo is concerned principally with the behavior of iterative
   resolvers, which are typically found as part of a recursive name
   server.  This memo uses the more precise term "iterative resolver",



Larson & Barber         Expires January 18, 2006                [Page 3]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


   because the focus is usually on that component.  In instances where
   the name server role of this entity requires mentioning, this memo
   uses the term "recursive name server".  As an example of the
   difference, the name server component of a recursive name server
   receives DNS queries and the iterative resolver component sends
   queries.

   The advent of IPv6 requires mentioning AAAA records as well as A
   records when discussing glue.  To avoid continuous repetition and
   qualification, this memo uses the general term "address record" to
   encompass both A and AAAA records when a particular situation is
   relevant to both types.







































Larson & Barber         Expires January 18, 2006                [Page 4]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


2.  Observed iterative resolver misbehavior

2.1  Aggressive requerying for delegation information

   There can be times when every name server in a zone's NS RRset is
   unreachable (e.g., during a network outage), unavailable (e.g., the
   name server process is not running on the server host) or
   misconfigured (e.g., the name server is not authoritative for the
   given zone, also known as "lame").  Consider an iterative resolver
   that attempts to resolve a query for a domain name in such a zone and
   discovers that none of the zone's name servers can provide an answer.
   We have observed a recursive name server implementation whose
   iterative resolver then verifies the zone's NS RRset in its cache by
   querying for the zone's delegation information: it sends a query for
   the zone's NS RRset to one of the parent zone's name servers.  (Note
   that queries with QTYPE=NS are not required by the standard
   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
   These NS queries represent this implementation's addition to that
   algorithm.)

   For example, suppose that "example.com" has the following NS RRset:

     example.com.   IN   NS   ns1.example.com.
     example.com.   IN   NS   ns2.example.com.

   Upon receipt of a query for "www.example.com" and assuming that
   neither "ns1.example.com" nor "ns2.example.com" can provide an
   answer, this iterative resolver implementation immediately queries a
   "com" zone name server for the "example.com" NS RRset to verify it
   has the proper delegation information.  This implementation performs
   this query to a zone's parent zone for each recursive query it
   receives that fails because of a completely unresponsive set of name
   servers for the target zone.  Consider the effect when a popular zone
   experiences a catastrophic failure of all its name servers: now every
   recursive query for domain names in that zone sent to this recursive
   name server implementation results in a query to the failed zone's
   parent name servers.  On one occasion when several dozen popular
   zones became unreachable, the query load on the com/net name servers
   increased by 50%.

   We believe this verification query is not reasonable.  Consider the
   circumstances: When an iterative resolver is resolving a query for a
   domain name in a zone it has not previously searched, it uses the
   list of name servers in the referral from the target zone's parent.
   If on its first attempt to search the target zone, none of the name
   servers in the referral is reachable, a verification query to the
   parent would be pointless: this query to the parent would come so
   quickly on the heels of the referral that it would be almost certain



Larson & Barber         Expires January 18, 2006                [Page 5]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


   to contain the same list of name servers.  The chance of discovering
   any new information is slim.

   The other possibility is that the iterative resolver successfully
   contacts one of the target zone's name servers and then caches the NS
   RRset from the authority section of a response, the proper behavior
   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
   the target zone is more trustworthy than delegation information from
   the parent zone.  If, while processing a subsequent recursive query,
   the iterative resolver discovers that none of the name servers
   specified in the cached NS RRset is available or authoritative,
   querying the parent would be wrong.  An NS RRset from the parent zone
   would now be less trustworthy than data already in the cache.

   For this query of the parent zone to be useful, the target zone's
   entire set of name servers would have to change AND the former set of
   name servers would have to be deconfigured or decommissioned AND the
   delegation information in the parent zone would have to be updated
   with the new set of name servers, all within the TTL of the target
   zone's NS RRset.  We believe this scenario is uncommon:
   administrative best practices dictate that changes to a zone's set of
   name servers happen gradually when at all possible, with servers
   removed from the NS RRset left authoritative for the zone as long as
   possible.  The scenarios that we can envision that would benefit from
   the parent requery behavior do not outweigh its damaging effects.

   This section should not be understood to claim that all queries to a
   zone's parent are bad.  In some cases, such queries are not only
   reasonable but required.  Consider the situation when required
   information, such as the address of a name server (i.e., the address
   record corresponding to the RDATA of an NS record), has timed out of
   an iterative resolver's cache before the corresponding NS record.  If
   the name of the name server is below the apex of the zone, then the
   name server's address record is only available as glue in the parent
   zone.  For example, consider this NS record:

     example.com.        IN   NS   ns.example.com.

   If a cache has this NS record but not the address record for
   "ns.example.com", it is unable to contact the "example.com" zone
   directly and must query the "com" zone to obtain the address record.
   Note, however, that such a query would not have QTYPE=NS according to
   the standard resolution algorithm.

2.1.1  Recommendation

   An iterative resolver MUST NOT send a query for the NS RRset of a
   non-responsive zone to any of the name servers for that zone's parent



Larson & Barber         Expires January 18, 2006                [Page 6]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005


   zone.  For the purposes of this injunction, a non-responsive zone is
   defined as a zone for which every name server listed in the zone's NS
   RRset:

   1.  is not authoritative for the zone (i.e., lame), or,

   2.  returns a server failure response (RCODE=2), or,

   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].


2.2  Repeated queries to lame servers

   Section 2.1 describes a catastrophic failure: when every name server
   for a zone is unable to provide an answer for one reason or another.
   A more common occurrence is when a subset of a zone's name servers
   are unavailable or misconfigured.  Different failure modes have
   different expected durations.  Some symptoms indicate problems that
   are potentially transient; for example, various types of ICMP
   unreachable messages because a name server process is not running or
   a host or network is unreachable, or a complete lack of a response to
   a query.  Such responses could be the result of a host rebooting or
   temporary outages; these events don't necessarily require any human
   intervention and can be reasonably expected to be temporary.

   Other symptoms clearly indicate a condition requiring human
   intervention, such as lame server: if a name server is misconfigured
   and not authoritative for a zone delegated to it, it is reasonable to
   assume that this condition has potential to last longer than
   unreachability or unresponsiveness.  Consequently, repeated queries
   to known lame servers are not useful.  In this case of a condition
   with potential to persist for a long time, a better practice would be
   to maintain a list of known lame servers and avoid querying them
   repeatedly in a short interval.

   It should also be noted, however, that some authoritative name server
   implementations appear to be lame only for queries of certain types
   as described in RFC 4074 [5].  In this case, it makes sense to retry
   the "lame" servers for other types of queries, particularly when all
   known authoritative name servers appear to be "lame".

2.2.1  Recommendation

   Iterative resolvers SHOULD cache name servers that they discover are
   not authoritative for zones delegated to them (i.e. lame servers).
   If this caching is performed, lame servers MUST be cached against the
   specific query tuple <zone name, class, server IP address>.  Zone
   name can be derived from the owner name of the NS record that was



Larson & Barber         Expires January 18, 2006                [Page 7]

Internet-Draft     Observed DNS Resolution Misbehavior         July 2005