One document matched: draft-fujiwara-dnsop-bad-dns-auth-00.txt

DNS Operations                                        K. Fujiwara
Internet-Draft                                               JPRS
Expires: April 18, 2005                                 K. Toyama
                                                     K. Ishibashi
                                                      NTT PF Labs
                                                 October 18, 2004
               DNS authoritative server misconfiguration
                    and a countermeasure in resolver
                draft-fujiwara-dnsop-bad-dns-auth-00.txt








Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).




Fujiwara                 Expires April 18, 2005                 [Page 1]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


Abstract

   This memo describes DNS authoritative name server misconfiguration
   and that results in a significant query cost in DNS resolver server.
   In some cases we recommend re-checking DNS authoritative servers with
   a viewpoint of current RFC and propose corresponding changes in DNS
   resolver server implementations to protect it. And more, we point
   open issues.

   The recommendations made in this document are based on analysis of
   abnormal DNS resolver server load at large ISP cache server which has
   many customers.







































Fujiwara                 Expires April 18, 2005                 [Page 2]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


1. Introduction

   This memo describes that a combination of misconfigurations of
   authoritative servers may lead significant heavy load to resolver
   servers.  This behavior was found through the observation of query
   traffic to/from resolver servers[NANOG32CACHE].  Here, the
   misconfiguation combinations are large RRset, EDNS0 unsupported and
   TCP filtering.

   While there are reports on the observations of query traffic to root
   or top-level domain servers and recommendation to the resolver
   servers[1, 2], this memo intends to notify to the operators of
   authoritative servers that their configuration can lead heavy load on
   resolver servers.

   As stated in [3], response size from DNS authoritative servers may
   grow as the use of IPv6 spreads.  Thus the above combination and the
   anomaly in resolver server caused by the combination will frequently
   occur.

   In the following sections, we describe the problem in detail.  We
   then recommend to re-check configurations of authoritative servers to
   avoid the problem.  We also show an example of resolver sever
   modification in case that operators of authoritative servers are not
   cooporative or, in extreme, malicious in that they intentionaly
   attempt to increase the load of resolver servers.

2. Poblem Description

   DNS message size is limited to 512 octets [RFC1035].  However, some
   response can exceed the limitation.  One typical case is the responce
   with PTR RRsets for an IP address which is assingned for many domain
   names.  If the authoritative server who returns such responce do not
   support EDNS0 option [RFC2671], the name server returns truncated
   responce (TC bit = 1) to the query sent by a resolver server.  Then
   the resolver server tries to get whole message by using TCP
   connction.  A problem occurs if the authoritative name server filters
   TCP packets.  In that case, because the resolver server cannot any
   establish TCP connections to the authoritative server, it hold the
   TCP SYN_SENT states for some interval.  Because holding TCP SYN_SENT
   states increase the load of the resolver server, this phonomenan can
   significantly impact on resolver server.

   When there are multiple name servers for the record, the resolver
   server repeats the sequence for all the name servers, depending on
   the implementation of the resolver server (At least, we found that
   the BIND follows this sequence).




Fujiwara                 Expires April 18, 2005                 [Page 3]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


   Finally, the resolver server responds users with ServFail, which is
   not cached by both resolver server and stub resolvers.

3. Authoritative servers

     In the viewpoint from resolver servers, authoritative servers MUST
   be configured correctly.

3.1 RRSet size

     DNS responses which fit in 512 octet are carried by UDP packet.
   [RFC1035] This case is safe and light for DNS resolver servers.
   Larger responses are carried by TCP virtual circuit or EDNS0 UDP
   packet only.

3.1.1 Recommendation

     DNS zone authors SHOULD write RRSet as small as possible and SHOULD
   NOT write useless RRs. And if they must write large RRSet which
   response packet size is larger than 512 octet, they MUST be
   especially careful to setup authoritative servers described in
   section 3.2 and 3.3.

3.2 TCP query issue

   There are many authoritative servers which filter or reject TCP
   queries.  There are many administrators who want to close DNS
   authoritative server TCP port.  Many of them compared the server's
   security and the issues caused by closing TCP port and they decide
   filtering TCP port.

   But filtering DNS authoritative server TCP port may causes problems
   described in section 2.  According to RFC1123 section 6.1.3.2, DNS
   servers MUST be able to service UDP queries and SHOULD be able to
   service TCP queries.

3.2.1 Recommendation

   DNS server administrator SHOULD re-check DNS authoritative server TCP
   setting and SHOULD configure the server to service TCP queries.

3.3 EDNS0

   EDNS0[RFC2671] extends UDP payload size.

   As noted in RFC1123 Section 6.1.3.2, UDP queries have much lower
   overhead, both in packet count and in connection state.




Fujiwara                 Expires April 18, 2005                 [Page 4]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


   To reduce TCP query cost, EDNS0 support is necessary.

   3.3.1 Recommendation

   DNS server administrator SHOULD support EDNS0 in their authoritative
   server if they write RRSet which response size exceeds 512 octet.

4. Resolver algorithm

4.1 TCP query necessity

   There are many resolver servers and stub resolvers which does not
   support EDNS0, they cannot handle answers of 512 octet and more.
   Therefore, supporting TCP queries is mandatory now.

   If EDNS0 is widespread and all of stub resolvers, resolver servers
   and authoritative servers support EDNS0, supporting TCP queries is
   still necessary because TCP is only method to send larger data than
   path MTU when IP fragment is prohibited.

4.2 Resolver algorithm improvement

   To avoid problems described in section 2, we tried to change existing
   resolver server not to query by TCP when truncation occurs and it
   reduces TCP sessions, but it cannot cache any data and it may violate
   RFC2181.

   Then, we propose new resolver algorithm to cache misconfigured
   servers.  In iterative query, resolver server should cache truncated
   answers information (servername, domainname, class, type, TC=1) and
   bad authoritative server information which does not answer TCP.  All
   the servers for a given domainname answers TC=1 and does not answer
   by TCP, the resolver server cache the domainname as "cannot resolve"
   for several period such as 3600 second.

   5 Conclusion

   In this document, we describe a observed anomaly of resolver servers
   caused by the combination of authoritative server misconfigurations;
   large RRset, EDNS0 unsupport, and TCP filtering.  Because size of
   RRset tends to increase, which increase the frequency of this
   phenomenon, which can severly impact on resolver servers.  Therefore,
   the operators of the authoritative server should re-check the
   configuration of their server. Meanwhile, we propose a modification
   of resolver server to protect againt the phenomenon, which can be
   caused by intentional DoS attacks to the resolver server.

6. Security considerations



Fujiwara                 Expires April 18, 2005                 [Page 5]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


   Misconfigurations of authoritative servers discussed in this document
   expose resolver servers to increased risk of intentional DDoS
   attacks.

   Modification of the resolver servers discussed in this memo can
   reduce the risk.

   Refefences

   [NANOG32CACHE] Chika Yoshimura, et al., "DNS Anomalies and Their
   Impact on DNS Cache Servers", Oct 2004, NANOG32

   [1]  M. Larson and P. Barber, "Observed DNS Resolution Misbehavior,"
   July 2004, draft-ietf-dnsop-bad-dns-res-02.txt

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

   [3]  P. Vixie and A. Kato, "DNS Response Size Issues," Internet
   Draft, July 2004, draft-ietf-dnsop-respsize-01.txt


   Authors' Addresses


      Kazunori Fujiwara
      Japan Registry Service Co.,Ltd.
      Chiyoda First Bldg. East 13F,
      3-8-1 Nishi-Kanda Chiyoda-ku,
      Tokyo 101-0065, JAPAN
      Ohone: +81-3-5215-8451
      E-Mail: fujiwara@jprs.co.jp

      Keisuke Ishibashi
      Nippon Telegraph and Telephone Corporation
      Information Sharing Platform Laboratories
      3-9-11 Midori-cho
      Musashino-shi, Tokyo 180-8585 Japan
      Phone: +81-422-59-3407
      E-Mail: ishibashi.keisuke@lab.ntt.co.jp

      Katsuyasu Toyama
      Nippon Telegraph and Telephone Corporation
      Information Sharing Platform Laboratories
      3-9-11 Midori-cho
      Musashino-shi, Tokyo 180-8585 Japan
      Phone: +81-422-59-7906
      E-Mail: toyama.katsuyasu@lab.ntt.co.jp



Fujiwara                 Expires April 18, 2005                 [Page 6]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


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 (2004).  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

   We would like to thank Ichiro Mizukoshi, Haruhiko Ohshima, Masahiro
   Ishino, Chika Yoshimura, Tsuyoshi Toyono, Hirotaka Matsuoka, Yasuhiro
   Morisita, and Bill Manning.



Fujiwara                 Expires April 18, 2005                 [Page 7]

Internet-Draft    DNS misconfiguration & countermeasure October 18, 2004


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

















































Fujiwara                 Expires April 18, 2005                 [Page 8]