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

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

   bandwidth.  A possible solution is to delegate these numeric TLDs
   from the root zone to a separate set of servers to absorb the
   traffic.  The "black hole servers" used by the AS 112 Project [8],
   which are currently delegated the in-addr.arpa zones corresponding to
   RFC 1918 [7] private use address space, would be a possible choice to
   receive these delegations.  Of course, the proper and usual root zone
   change procedures would have to be followed to make such a change to
   the root zone.

2.10  Misdirected recursive queries

   The root name servers receive a significant number of recursive
   queries (i.e., queries with the RD bit set in the header).  Since
   none of the root servers offers recursion, the servers' response in
   such a situation ignores the request for recursion and the response
   probably does not contain the data the querier anticipated.  Some of
   these queries result from users configuring stub resolvers to query a
   root server.  (This situation is not hypothetical: we have received
   complaints from users when this configuration does not work as
   hoped.)  Of course, users should not direct stub resolvers to use
   name servers that do not offer recursion, but we are not aware of any
   stub resolver implementation that offers any feedback to the user
   when so configured, aside from simply "not working".

2.10.1  Recommendation

   When the IP address of a name server that supposedly offers recursion
   is configured in a stub resolver using an interactive user interface,
   the resolver could send a test query to verify that the server indeed
   supports recursion (i.e., verify that the response has the RA bit set
   in the header).  The user could be immediately notified if the server
   is non-recursive.

   The stub resolver could also report an error, either through a user
   interface or in a log file, if the queried server does not support
   recursion.  Error reporting SHOULD be throttled to avoid a
   notification or log message for every response from a non-recursive
   server.

2.11  Suboptimal name server selection algorithm

   An entire document could be devoted to the topic of problems with
   different implementations of the recursive resolution algorithm.  The
   entire process of recursion is woefully under specified, requiring
   each implementor to design an algorithm.  Sometimes implementors make
   poor design choices that could be avoided if a suggested algorithm
   and best practices were documented, but that is a topic for another
   document.



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


   Some deficiencies cause significant operational impact and are
   therefore worth mentioning here.  One of these is name server
   selection by an iterative resolver.  When an iterative resolver wants
   to contact one of a zone's authoritative name servers, how does it
   choose from the NS records listed in the zone's NS RRset?  If the
   selection mechanism is suboptimal, queries are not spread evenly
   among a zone's authoritative servers.  The details of the selection
   mechanism are up to the implementor, but we offer some suggestions.

2.11.1  Recommendation

   This list is not conclusive, but reflects the changes that would
   produce the most impact in terms of reducing disproportionate query
   load among a zone's authoritative servers.  I.e., these changes would
   help spread the query load evenly.

   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
      be treated equally.  (In the case of the "com" zone, for example,
      most of the root servers return the NS record for "a.gtld-
      servers.net" first in the authority section of referrals.
      Apparently as a result, this server receives disproportionately
      more traffic than the other 12 authoritative servers for "com".)

   o  Use all NS records in an RRset.  (For example, we are aware of
      implementations that hard-coded information for a subset of the
      root servers.)

   o  Maintain state and favor the best-performing of a zone's
      authoritative servers.  A good definition of performance is
      response time.  Non-responsive servers can be penalized with an
      extremely high response time.

   o  Do not lock onto the best-performing of a zone's name servers.  An
      iterative resolver SHOULD periodically check the performance of
      all of a zone's name servers to adjust its determination of the
      best-performing one.















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


3.  IANA considerations

   There are no new IANA considerations introduced by this memo.
















































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


4.  Security considerations

   The iterative resolver misbehavior discussed in this document exposes
   the root and TLD name servers to increased risk of both intentional
   and unintentional denial of service attacks.

   We believe that implementation of the recommendations offered in this
   document will reduce the amount of unnecessary traffic seen at root
   and TLD name servers, thus reducing the opportunity for an attacker
   to use such queries to his or her advantage.









































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


5.  Internationalization considerations

   There are no new internationalization considerations introduced by
   this memo.

6.  Informative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
        RFC 2181, July 1997.

   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
        RFC 2308, March 1998.

   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
        Queries for IPv6 Addresses", RFC 4074, May 2005.

   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
        April 1997.

   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
        Lear, "Address Allocation for Private Internets", BCP 5,
        RFC 1918, February 1996.

   [8]  <http://www.as112.net>


Authors' Addresses

   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   Email: [e-mail]









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


   Piet Barber
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   Email: [e-mail]












































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


Intellectual Property Statement

   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
   [e-mail].


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Larson & Barber         Expires January 18, 2006               [Page 21]