DNS Operations K. Fujiwara Internet-Draft JPRS Expires: August 14, 2005 Febrary 14, 2005 DNS transport issues draft-fujiwara-dnsop-dns-transport-issue-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 August 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes DNS transport issues in DNS shared unicast environment. Recently, many root DNS servers and some TLD servers Fujiwara Expires August 14, 2005 [Page 1] Internet-Draft DNS transport issues Febrary 14, 2005 have introduced DNS shared unicast technique for DNS authoritative services, this may cause some problems. Fujiwara Expires August 14, 2005 [Page 2] Internet-Draft DNS transport issues Febrary 14, 2005 1. Introduction In DNS, There are roughly three kinds of DNS communications, recursive query resolution from stub resolver to iterative server, iterative queries from iterative server to authoritative server, and zone transfer between authoritative servers. This document mainly describes iterative queries from iterative server to authoritative server. DNS uses three types of transports, basic UDP transport (limited to 512 octets) [RFC1035], TCP transport (over 512 and lower than 65536 octets) [RFC1035] and EDNS0 UDP transport[RFC2671]. Recently, many root DNS servers and some TLD servers use DNS shared unicast techniche[RFC3258] for DNS service. Shared unicast technique influences IP packet reachability between authoritative server and iterative server. this is described in section 2. TCP transport needs high cost and inquiry failure brings an awful load to the iterative servers. It is necessary to think the ISP iterative servers should resolve the name and how much cost can be paid. 2. DNS transports under DNS shared unicast Suppose communication between an iterative server which has one unique IP address and multiple shared unicast authoritative DNS servers which shares one IP address. To which real authoritative server reach the DNS query from the iterative server is selected by the routing protocol and may sometimes change. On the other hand, replies from the all authoritative servers which share one IP address allways reach the iterative server. 2.1 Basic UDP transport case As described in RFC3258 section 2.5, this UDP transport has no problem. 2.2 EDNS0 UDP transport case Any DNS query packet is smaller than 512 octets and fit in one UDP packet because DNS domainname is smaller than 256 octets. DNS response packet may be larger than path MTU, then DNS response packet mey be fragmented to multiple fragment packets. A DNS query packet reaches one of shared authoritative servers and fragmented response packets returns to the iterative server. It works fine even if route flaps. Fujiwara Expires August 14, 2005 [Page 3] Internet-Draft DNS transport issues Febrary 14, 2005 2.3 TCP transport case As described in RFC3258 section 2.5, TCP transport may have problems. Without per packet load sharing, most queries over TCP session may sucess because DNS query session is short time and routes may be stable during DNS query session in most cases. With per packet load sharing, special cosideration is needed. But some transit ISPs use per packet load sharing in BGP4 routing. It is prohibited in RFC1771 BGP4 protocol. Transit ISPs is not under shared unicast DNS service provider. As a result, TCP connection to shared unicast DNS server may fail frequently. 3. DNS packet size As described in RFC3226 "DNSSEC and IPv6 A6 aware server/resolver message size requirements", DNSSEC compliant servers and resolvers MUST support EDNS0 and SHOULD advertise message size of 4000. Recently, without DNSSEC, As a result of adding IPv6 AAAA glue RRs in the root zone and TLD zones, EDNS0 necessity has risen. EDNS0 message size of 4000 is enough in many cases. But as described in [draft-fujiwara-bad-dns-auth], some people writes very large RRset which cannot be carried by 4000-octet-EDNS0, it is necessary to use TCP transport as last resort. 4. Other requirements 4.1 IPv6 fragmentation issue As described in RFC2460 "IPv6 Specification" section 5, "the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU." But EDNS0 needs to use IP fragmentation to avoid TCP. 4.2 pMTU discovery Especially in IPv6 environment, it is necessary to consider pMTU discovery setting to pass larger data which need to be fragmented. EDNS0 with fragmentation does not work well without pMTU discovery. 5. Iterative server cost-effectiveness TCP transport needs high cost for both authoritative servers and Fujiwara Expires August 14, 2005 [Page 4] Internet-Draft DNS transport issues Febrary 14, 2005 iterative servers. Iterative servers case, inquiry failure brings an awful load. It is necessary to consider the ISP iterative servers should resolve the name by TCP and how much cost can be paid. As described in section 2.3, TCP queries may fail, it is necessary to consider frequent TCP failure to implement iterative server. TBD 6. Future proposal In the future, any DNS server MUST support EDNS0. Furthermore, it is not necessary to consider EDNS0 unaware iterative servers. In the case, if any response from root/TLD zone is smaller than 4000 octets, the root/TLD authoritative servers need not answer TCP query. TBD 7. Security considerations TBD References [I-D. fujiwara-dnsop-bad-dns-auth] K. Fujiwara, K.Toyama, and K.Ishibashi, "DNS authoritative server misconfiguration and a countermeasure in resolver" draft-fujiwara-dnsop-bad-dns-auth-01 (work in progress), Oct. 2004. [RFC3226] O. Gudmundsson, "DNSSEC and IPv6 A6 aware server/resolver message size requirements, " RFC 3226 December 2001. [RFC3258] T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast Addresses" RFC 3258 April 2002. [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. [RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998. Fujiwara Expires August 14, 2005 [Page 5] Internet-Draft DNS transport issues Febrary 14, 2005 [RFC2181] R. Elz and R. Bush, "Clarifications to the DNS Specification," RFC 2181, July 1997. 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 Phone: +81-3-5215-8451 E-Mail: fujiwara@jprs.co.jp Fujiwara Expires August 14, 2005 [Page 6] Internet-Draft DNS transport issues Febrary 14, 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 (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 August 14, 2005 [Page 7] Internet-Draft DNS transport issues Febrary 14, 2005 Funding for the RFC Editor function is currently provided by the Internet Society. Fujiwara Expires August 14, 2005 [Page 8]