Internet DRAFT - draft-fujiwara-dnsop-bad-dns-auth

draft-fujiwara-dnsop-bad-dns-auth






DNS Operations                                               K. Fujiwara
Internet-Draft                                                      JPRS
Expires: January 19, 2006                                   K. Ishibashi
                                                               K. Toyama
                                                             NTT PF Labs
                                                            C. Yoshimura
                                                      NTT Communications
                                                           July 18, 2005


DNS authoritative server misconfiguration and countermeasure in resolver
                draft-fujiwara-dnsop-bad-dns-auth-03.txt

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 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes misconfigurations of DNS authoritative servers
   and its effect to old DNS iterative resolver servers we experienced.
   We recommend re-checking DNS authoritative server configuration and
   advise using newer iterative resolver server implementations.  The



Fujiwara, et al.        Expires January 19, 2006                [Page 1]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


   recommendations made in this document are based on analysis of
   abnormal DNS resolver server load at large ISP resolver server which
   has many customers.  This is not protocol issue.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Problem Description  . . . . . . . . . . . . . . . . . . . . . 3
   3.   Re-checking of Authoritative servers . . . . . . . . . . . . . 4
   4.   Iterative resolver server requirements . . . . . . . . . . . . 4
   5.   Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.   Security considerations  . . . . . . . . . . . . . . . . . . . 5
   7.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
        Intellectual Property and Copyright Statements . . . . . . . . 8



































Fujiwara, et al.        Expires January 19, 2006                [Page 2]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


1.  Introduction

   There are many misconfigured DNS authoritative servers.  They have
   large RRSets whose response size exceeds 512 octets, they does not
   support EDNS0 extension, and they does not answer TCP DNS query.  In
   this case, over 512 octets RRSets cannot be resolved.

   This memo describes that combination of misconfigurations at
   authoritative servers can create significant overloads on resolver
   servers, especially old but spreaded BIND 8.

   While there are reports on the observations of query traffic to root
   or top-level domain servers and the recommendations to the resolver
   servers to reduce anomalies on the servers
   [draft-ietf-dnsop-bad-dns-res-03], [WESSELS04], this memo intends to
   notify to the operators of authoritative servers that their
   configuration can lead resolver servers' problems.

   In the following sections, we provide a detailed explanation of the
   problem.  We then recommend to re-check the configurations of
   authoritative servers to avoid the problem.  At last, we describe
   iterative resolver server's recommendation.

2.  Problem Description

   DNS message size is limited to 512 octets in original UDP packet
   [RFC1035].  However, it is possible to write large RRSet which
   exceeds 512 octets.  A typical case observed is a response with PTR
   RRSet for an IP address which is assigned for many (over 300) domain
   names [TOYAMA04].  Another case, many A RRs to one domain name for
   load balancing or by writing many SRV RRs to large domain name for
   Active Directory.

   Iterative resolver servers send queries to authoritative servers.  If
   one authoritative server which returns such large response does not
   support EDNS0 and sufficient maximum payload size [RFC2671], the
   server returns truncated response (TC bit = 1) to the resolver
   server.  Then the resolver server tries to get whole message by using
   TCP transport.

   If the authoritative server which returns such large response does
   not support TCP transport or filters TCP DNS port, the DNS query
   fails.  There are multiple authoritative servers for the record, the
   resolver server repeats the sequence for all the authoritative
   servers.  If all authoritative servers for the RRSet are
   misconfigured and does not answer by TCP, the DNS query cannot be
   resolved and the resolver server responds ServFail error to stub
   resolver.  If the authoritative server filters TCP DNS port and does



Fujiwara, et al.        Expires January 19, 2006                [Page 3]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


   not send TCP reset, the resolver server must wait till TCP timeout.

   This RRSet status cannot be cached by both resolver servers and stub
   resolvers.  This case corresponds to [RFC2308] section 7.2 Dead /
   Unreachable Server.  Dead or unreachable server information may be
   cached in 5 minutes.  As the result, there are many queries to
   misconfigured authoritative servers.

   The problem we faced is significant overloads of BIND 8 resolver
   servers.  BIND 8 resolver server starts a iterative query at every
   query from stub resolvers (when there are no cached data for that
   query) and it keeps a TCP SYN_SENT state for some interval.  There
   were many queries for unresolvable RRSet and keeping many TCP states
   increased the load of the resolver server.  This phenomenon impacted
   significantly the resolver server performance.  These unresolvable
   RRSets are well-known addresses.

   While BIND 9 iterative resolver server is resolving one domainname,
   it does not try to resolve the same queries and it will answer same
   response at the first query completion.  Therefore, BIND 9 is not
   affected.

3.  Re-checking of Authoritative servers

   Authoritative DNS servers with large RRSets whose response size may
   exceeds 512 octets must answer TCP DNS query and should support
   EDNS0.  Or the RRset cannt be resolved.

   System administrators manage TCP filters carefully and some of them
   does not know about DNS.  As a result, some administrators filters
   their DNS server's TCP port.

   Therefore, the operators of the authoritative servers should know
   about DNS and should re-check the configuration of their servers.

4.  Iterative resolver server requirements

   There are authoritative DNS servers with TCP filer problems.  ISP DNS
   resolver servers must resolve or answer any query which ISP customer
   queries.  Even if they receive unresolvable queries, they must work
   well.  So, using tough iterative resolver server implementation is
   necessary.

   Currently, any BIND 8 version have this weak-point.  Using BIND 9 is
   one solution.






Fujiwara, et al.        Expires January 19, 2006                [Page 4]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


5.  Conclusion

   Reducing unresolvable RRSets is necessary.  But there still exist
   misconfigurations.  Iterative resolver servers which support many
   users must be tough.  So, using older implementation should be
   deprecated.

6.  Security considerations

   Older iterative resolver server implementations especially old but
   spreaded BIND 8 may have weak-points.  Using older and weak
   implementations should be deprecated.

7.  References

   [TOYAMA04]
              Toyama, K., "DNS Anomalies and Their Impact on DNS Cache
              Servers", NANOG 32, October 2004.

   [draft-ietf-dnsop-respsize-01]
              Vixie, P. and A. Kato, "DNS Response Size Issues (work in
              progress)", July 2004.

   [draft-ietf-dnsop-bad-dns-res-03]
              Larson, M. and P. Barber, "Observed DNS Resolution
              Misbehavior", October 2004.

   [WESSELS04]
              Wessels, D., "Is Your Caching Resolver Polluting the
              Internet?", SIGCOMM Network Troubleshooting, August 2004.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.












Fujiwara, et al.        Expires January 19, 2006                [Page 5]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


Authors' Addresses

   Kazunori Fujiwara
   Japan Registry Services Co.,Ltd.
   Chiyoda First Bldg. East 13F
   3-8-1 Nishi-Kanda Chiyoda-ku
   Tokyo  101-0065
   JAPAN

   Phone: +81-3-5215-8451
   Email: fujiwara@jprs.co.jp


   Keisuke Ishibashi
   Information Sharing Platform Laboratories, Nippon Telegraph and Telephone Corporation
   3-9-11 Midori-cho
   Musashino-shi
   Tokyo  180-8585
   JAPAN

   Phone: +81-422-59-3407
   Email: ishibashi.keisuke@lab.ntt.co.jp


   Katsuyasu Toyama
   Information Sharing Platform Laboratories, Nippon Telegraph and Telephone Corporation
   3-9-11 Midori-cho
   Musashino-shi
   Tokyo  180-8585
   JAPAN

   Phone: +81-422-59-7906
   Email: toyama.katsuyasu@lab.ntt.co.jp


   Chika Yoshimura
   NTT Communications Corporation
   NTT OTEMACHI BLDG.
   2-3-5 Otemachi, Chiyoda-ku
   Tokyo  100-0004
   JAPAN

   Phone: +81-3-6800-6113
   Email: yosimura@ocn.ad.jp

Appendix A.  Acknowledgements

   We would like to thank Ichiro Mizukoshi, Haruhiko Ohshima, Masahiro



Fujiwara, et al.        Expires January 19, 2006                [Page 6]

Internet-Draft    DNS misconfiguration & countermeasure        July 2005


   Ishino, Chika Yoshimura, Tsuyoshi Toyono, Hirotaka Matsuoka, Yasuhiro
   Morisita, and Bill Manning.

















































Fujiwara, et al.        Expires January 19, 2006                [Page 7]

Internet-Draft    DNS misconfiguration & countermeasure        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
   ietf-ipr@ietf.org.


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.




Fujiwara, et al.        Expires January 19, 2006                [Page 8]