INTERNET-DRAFT Donald E. Eastlake, 3rd Updates RFC 1035 CyberCash Expires May 1998 November 1997 Larger Domain Name System UDP Replies ------ ------ ---- ------ --- ------- Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnsind-udp-size-00.txt, is intended to be become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the DNS mailing list <namedroppers@internic.net> or to the author. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Abstract The Domain name system defaults to using UDP for queries and replies with a DNS payload limit of 512 bytes. Larger replies cause an initial truncation indication leading to a subsequent handling via TCP with substantially higher overhead. A upward compatible extension to DNS requests is specified which frequently permits larger UDP responses reducing the need for use of TCP. Donald E. Eastlake, 3rd [Page 1]
INTERNET-DRAFT Larger DNS UDP Replies Acknowledgement Paul Vixie originated the basic idea specified herein. Table of Contents Status of This Document....................................1 Abstract...................................................1 Acknowledgement............................................2 Table of Contents..........................................2 1. Introduction............................................3 2. Permitting Larger DNS UDP Packets.......................3 3. Security Considerations.................................4 References.................................................5 Author's Addresses.........................................5 Expiration and File Name...................................5 Donald E. Eastlake, 3rd [Page 2]
INTERNET-DRAFT Larger DNS UDP Replies 1. Introduction The global Internet Domain Name System (DNS) is documented in RFC 1034, 1035, and numerous additional Requests for Comment. It provides a distributed hierarchical database with redundant servers. Recently security features have been added to the DNS [RFC 2065]. DNS can transfer data via both UDP and TCP. Some requests that are very likely to have big responses, most commonly zone transfers, just use TCP. However, the vast majority of requests are initially sent via UDP which causes the response to be via UDP. DNS over UDP is constrained to one packet for the request, which is normally no problem as requests are usually small, and one packet for response, which can be a problem. The DNS data portion of DNS UDP packets is currently limited to 512 bytes. If data required to be in the response does not fit, a truncation flag bit is set and the resolver must try again using TCP with its substantially higher set up and tear down overhead. As signatures and/or keys are included in more responses due to DNS security [RFC 2065], especially large modulus RSA signatures/keys, and average domain names get longer and there are increasing numbers of instances of larger RRsets including larger addresses for IPv6 [RFC 1886], the UDP response size limit will increasingly be exceeded. Yet the bulk of the network has MTUs on the order of the Ethernet MTU or larger. Consideration is being given to increasing the minimum MTU for IPv6 networks to 1280 bytes from 576 bytes. (Links with a smaller MTU would simply need a link adaptation layer, as is currently required for ATM with its tiny MTU.) 2. Permitting Larger DNS UDP Packets No change is proposed in the size limit on UDP queries. It remains at 512 bytes However, the presently unused RCODE field in UDP queries is redefined to specify the resolver imposed limit on the DNS data in the UDP response. This four bit field is presently zero. Values from 1 through 7 are defined as follows: Donald E. Eastlake, 3rd [Page 3]
INTERNET-DRAFT Larger DNS UDP Replies RCODE DNS data limit in bytes 0 512 (current default) 1 768 2 1280 (new default) 3 1720 4 3200 5 4800 6 8000 7 12000 8-14 -reserved A resolver should take into account its local buffer space and any knowledge it has about the local network MTU (maximum transmission unit) or the PMTU (path MTU) to the server it is querying. Making a reasonable allowance for IP headers that may be added by the server, the resolver should then pick an RCODE value from the above table. In the absence of any information, the value 2 should be used. It is not intended that the resolver do any sort of PMTU discovery just to provide a more accurate RCODE. The packets required for PMTU discovery would defeat the purpose of avoiding the additional packets required by TCP. A server, on receiving a query with a non-zero RCODE, should limit its DNS response message to that size but may need to limit it to a lower amount due to buffer space available. It should also limit it to the local network MTU or the PMTU to the resolver, if known, less a reasonable allowance for IP headers. An IPv6 server should enable fragmentation on UDP replies. While fragmentation will not be frequent if the above guidelines are followed, it may occur on occasion. 3. Security Considerations In the absence of request security, the request RCODE could be modified in transit. If set lower, this might result in unnecessary TCP. If set higher, this might result in unnecessary fragmentation. Donald E. Eastlake, 3rd [Page 4]
INTERNET-DRAFT Larger DNS UDP Replies References RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. RFC 1035 - P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", 01/03/1997. Author's Addresses Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 978 287 4877 +1 703 620-4200 (main office, Reston, VA) FAX: +1 978 371 7148 EMail: dee@cybercash.com Expiration and File Name This draft expires May 1998. Its file name is draft-ietf-dnsind-udp-size-00.txt. Donald E. Eastlake, 3rd [Page 5]
