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]
