DNS Operations K. Fujiwara
Internet-Draft JPRS
Expires: August 21, 2005 K. Toyama
K. Ishibashi
NTT PF Labs
C. Yoshimura
NTT Communications
Febrary 21, 2005
DNS authoritative server misconfiguration
and a countermeasure in resolver
draft-fujiwara-dnsop-bad-dns-auth-02.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
Fujiwara Expires August 21, 2005 [Page 1]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
Copyright (C) The Internet Society (2005).
Abstract
This memo describes misconfigurations of DNS authoritative name
server and its effect of increasing the load in DNS resolver server.
In some cases we recommend re-checking DNS authoritative servers with
a viewpoint of current RFC and point tough DNS resolver server
implementation requirements.
The recommendations made in this document are based on analysis of
abnormal DNS resolver server load at large ISP resolver server which
has many customers.
Fujiwara Expires August 21, 2005 [Page 2]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
1. Introduction
This memo describes that combination of misconfigurations at
authoritative servers can create significant overloads on resolver
servers, especially old but spreded BIND 8. Specifically, the
combinations of large response size, non-use of EDNS0 option and TCP
filtering at authoritative servers may increase the number of TCP
SYN_SENT status in resolver servers and the load on the servers.
This behavior was found through the observation of query traffic
to/from ISP resolver servers [TOYAMA04].
Currently, response sizes from DNS authoritative servers have been
grown by writing many A RRs to one name for load balancing or by
writing many SRV RRs to large domainname for Active Directory. And
more, response sizes may grow as the use of IPv6 or DNSSEC spread [I-
D. ietf-dnsop-respsize] [RFC3226]. In ENUM and SIP, many NAPTR
resource records may be written to a domainname.
Thus the above combination and the anomalies in resolver servers will
frequently occur.
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 [I-D. ietf-dnsop-band-dns-
res] , [WESSELS04], this memo intends to notify to the operators of
authoritative servers that their configuration can lead overload on
resolver servers.
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 UDP packet[RFC1035].
However, some response can exceed the limitation. A typical case
observed is a response with PTR RRsets for an IP address which is
assigned for many domain names [TOYAMA04]. Another case, many A RRs
to one name for load balancing or by writing many SRV RRs to large
domainname for Active Directory. Besides, spread of IPv6 and DNSSEC
may also increase the cases.
If the authoritative server who returns such response do not support
EDNS0 option [RFC2671], the server returns truncated response (TC bit
= 1) to the query sent by a resolver server. Then the resolver
server tries to get whole message by using TCP connection. A problem
occurs if the authoritative name server filters TCP DNS port. In
Fujiwara Expires August 21, 2005 [Page 3]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
that case, because the resolver server cannot establish a TCP
connection to the authoritative server, it keep the TCP SYN_SENT
states for some interval. Because keeping many TCP states increase
the load of the resolver server, this phenomenon can significantly
impact on the resolver server.
When there are multiple authoritative name servers for the record,
the resolver server repeats the sequence for all the authoritative
name servers, depending on the implementation of the resolver server
(At least, we found that the BIND follows this sequence).
Finally, the resolver server responds with ServFail to stub resolver,
which is not cached by both the resolver server and the 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
[RFC1123], DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries.
Fujiwara Expires August 21, 2005 [Page 4]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
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] relaxes the DNS message size limit.
As noted in RFC1123 Section 6.1.3.2, UDP queries have much lower
overhead, both in packet count and in connection state.
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 octets.
4. Iterative resolver server
4.1 BIND9 iterative server advantage
When a BIND9 iterative resolver server receives queries for a name
while the server resolves the same name, the server does not try to
resolve the following queries. When the resolve process finishes for
the
first query, whether it succeeded or not, the server responses the
results for all queries. Therefore, for implementations such as
BIND9, the problem described in section 2 will not occur.
4.2 Tough resolver necessity
Badly configured DNS authoritative server which filters TCP will be
increased and RRset may be larger than 512 octets. And more, Recently
many root servers and some TLD servers introduce RFC3258 style
anycast technique to their DNS authoritative servers. As described in
RFC3258 section 2.5, TCP transport may have problems with shared
unicast (anycast) DNS authoritative servers. So, the case which TCP
connection cannot be established when fallback to TCP occur will
increase and tough iterative resolver server implementation is
necessary.
4.3 Resolving cost vs effect for customers
In many cases, queries with TCP fallback cannot be resolved or may be
useless because of misconfigration. All authoritative servers which
have large RRsets should support ENDS0 and ISP iterative resolver
Fujiwara Expires August 21, 2005 [Page 5]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
server should support EDNS0. Effective answers may be fit in 4000
octets packet and it is carried by EDNS0. Best case, there are no TCP
fallback. To support TCP failback queries, ISP iterative resolver
server must spend great cost. It is useless to spend great cost for
the query with almost no meaning. Then, ignoring TCP fallback is
realistic. It cannot support all, but it can support almost all
customer's almost all queries. To consider maximum benefit, ingoring
useless queries is better than coping with all queries properly. In
case of ISP iterative resolver server, ignoring TCP fallback is
practical for the maximum customer's profit.
To support as much as possible, managing bad-TCP-reply authoritative
server list is better than ignoring all TCP fallback.
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 severely impact on resolver servers.
Therefore, the operators of the authoritative server should re-check
the configuration of their server. And tough iterative server
implementation is required. In case of ISP iterative resolver
server, Ignoring TCP fallback is practical for the maximum customer's
profit.
6. Security considerations
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.
References
[TOYAMA04] Katsuyasu Toyama, et al., "DNS Anomalies and Their Impact
on DNS Cache Servers", October 2004, NANOG32
[I-D. ietf-dnsop-respsize] P. Vixie and A. Kato, "DNS Response Size
Issues," draft-ietf-dnsop-respsize-01 (work in progress), July 2004.
[RFC3226] O. Gudmundsson, "DNSSEC and IPv6 A6 aware server/resolver
message size requirements, " RFC 3226 December 2001.
[I-D. ietf-dnsop-band-dns-res] M. Larson and P. Barber, "Observed DNS
Fujiwara Expires August 21, 2005 [Page 6]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
Resolution Misbehavior," draft-ietf-dnsop-band-dns-res-02 (work in
progress), July 2004.
[WESSELS04] D. Wessels, "Is Your Caching Resolver Polluting the
Internet?," SIGCOMM Network Troubleshooting, August 2004.
[RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION, " RFC 1035, November 1987.
[RFC2671] P. Vixie, "Extension Mechanisms for DNS (EDNS0)," RFC 2671,
August 1999.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support," RFC 1123, October 1989.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999.
[RFC2874] M. Crawford and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering, " RFC 2874, July 2000.
[RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC 2460, December 1998.
[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
Specification," RFC 2181, July 1997.
[RFC3258] T. Hardie, "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April 2002.
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
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
Fujiwara Expires August 21, 2005 [Page 7]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
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
Chika Yoshimura
NTT Communications Corporation
NTT OTEMACHI BLDG.,
2-3-5 Otemachi, Chiyoda-ku,
Tokyo 100-0004 JAPAN
Phone: +81-3-6800-6113
E-Mail: yosimura@ocn.ad.jp
Fujiwara Expires August 21, 2005 [Page 8]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 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
We would like to thank Ichiro Mizukoshi, Haruhiko Ohshima, Masahiro
Ishino, Chika Yoshimura, Tsuyoshi Toyono, Hirotaka Matsuoka, Yasuhiro
Morisita, and Bill Manning.
Fujiwara Expires August 21, 2005 [Page 9]
Internet-Draft DNS misconfiguration & countermeasure Febrary 21, 2005
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fujiwara Expires August 21, 2005 [Page 10]