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

非常好的dns解析软件

DNS Operations                                                 M. Larson
Internet-Draft                                                 P. Barber
Expires: August 14, 2006                                        VeriSign
                                                       February 10, 2006


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

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 August 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 August 14, 2006                [Page 1]

Internet-Draft     Observed DNS Resolution Misbehavior     February 2006


   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.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  Internationalization considerations  . . . . . . . . . . . . . 20
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22












Larson & Barber          Expires August 14, 2006                [Page 2]

Internet-Draft     Observed DNS Resolution Misbehavior     February 2006


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 August 14, 2006                [Page 3]

Internet-Draft     Observed DNS Resolution Misbehavior     February 2006


   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 August 14, 2006                [Page 4]

Internet-Draft     Observed DNS Resolution Misbehavior     February 2006


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 August 14, 2006                [Page 5]

Internet-Draft     Observed DNS Resolution Misbehavior     February 2006


   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.