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]