INTERNET-DRAFT Donald E. Eastlake, 3rd Updates RFC 1035 CyberCash Expires August 1998 February 1998 Bigger Domain Name System UDP Replies ------ ------ ---- ------ --- ------- Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnsind-udp-size-01.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), ftp.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. An extension to DNS UDP requests is specified which frequently permits larger UDP responses thus reducing the need for use of TCP. Donald E. Eastlake, 3rd [Page 1]
INTERNET-DRAFT Bigger DNS UDP Replies Acknowledgements Paul Vixie originated the basic idea specified herein. Some errors notice by Chris Thompson in verion -00 have been fixed. Table of Contents Status of This Document....................................1 Abstract...................................................1 Acknowledgements...........................................2 Table of Contents..........................................2 1. Introduction............................................3 2. Permitting Larger DNS UDP Packets.......................3 3. Compatibility Discussion................................5 4. Security Considerations.................................5 References.................................................6 Author's Addresses.........................................6 Expiration and File Name...................................6 Donald E. Eastlake, 3rd [Page 2]
INTERNET-DRAFT Bigger 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. The standard states that if the data required to be in the response to a UDP request does not fit in 512 bytes, a truncation flag bit is set in the response and the resolver must try again using TCP with TCP's substantially higher set up and tear down overhead. As signatures and/or keys are included in more responses due to DNS security [RFC 2065] and average domain names get longer and larger addresses for IPv6 [RFC 1886] come into use and there are increasing numbers of instances of larger RRsets, the old 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 (in some cases simulated by link adaptation layers that disguise a smaller physical MTU) and all modern IP stacks can handle buffering of that size or larger. 2. Permitting Larger DNS UDP Packets Efforts are under way to define an additional information resource record that can be used to communicate exact buffer sizes and other information. However, many older DNS servers ignore any request with a non-empty additional information section. Pending deployment of some such more exact and comprehensive solution, the following change is made in the DNS over UDP protocol. No change is made in the size limit on UDP queries. It remains at 512 bytes. 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 specified as zero. Values from 1 through 7 are defined as follows: Donald E. Eastlake, 3rd [Page 3]
INTERNET-DRAFT Bigger DNS UDP Replies RCODE DNS data limit in bytes 0 512 (current default) 1 768 2 1280 (new default) 3 1920 4 3200 (appropriate for all FDDI UDP) 5 4800 6 8000 7 12000 8-15 -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. A value that might be expected to cause a reply packet to fragment into two pieces is still preferable to using TCP. In the absence of any information, the value 2 should be used. The resolver should not do PMTU discovery just to provide a more accurate RCODE. The additional 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, MUST limit its DNS response message to the size specified but may need to limit it to a lower amount due to buffer space available. It SHOULD also limit it based on local network MTU or the PMTU to the resolver, if known, less a reasonable allowance for IP headers. 1280 bytes of DNS data is chosen as the new default to provide a generous allowance for IP headers and still be within the highly prevalent approximately Ethernet size or larger MTU and buffering generally available today. (It should also be noted that consideration is being given to increasing the original IPv6 minimum MTU from 576 to 1280 bytes.) 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. In principle, IPv6 headers and options could be huge, resulting in a very large UDP packet even though the DNS payload is limited, but this should not occur in practice. Donald E. Eastlake, 3rd [Page 4]
INTERNET-DRAFT Bigger DNS UDP Replies 3. Compatibility Discussion No cases are known where the above change will cause a problem for non-recursive queries. Old servers will ignore the RCODE field of the UDP query and should return 512 or fewer bytes, possibly with a truncation indication. Servers with this feature included should use the RCODE value to determine a ceiling on the size of response they will send. Non-zero values of RCODE will permit them to send larger UDP responses if local conditions are appropriate. There is a potential problem with recursive queries. If (1) an updated recursive query specifies bigger UDP responses with a non- zero RCODE to an old server and (2) that server in turn issues a corresponding query into which it blindly copies the RCODE field and (3) this corresponding query goes to an updated server that honors the non-zero RCODE field and (4) the updated server response DNS data is actually larger than 512 bytes as permitted by the RCODE in the query, then the intermediate old DNS server may be confused by the larger than 512 byte DNS response it receives. However, there are already DNS implementations out there on the Internet that send back larger than 512 byte responses in violation of the old standard and DNS implementations are being deployed which protect themselves against and are not confused by larger than expected responses. Should the above problem manifest itself, it can be cured by making the queries be TCP based or non-recursive or by upgrading the intermediate DNS server to which the recursive queries are being sent to implement this bigger UDP packet feature. There are cases, such as resolvers behind a firewall that can only get outside DNS information via a recursive server and changing to non-recursive queries is not possible. Upgrading the DNS server is the strongly recommended solution. 4. Security Considerations General DNS security issues are considered in RFC 2065. In the absence of request security [RFC 2065], 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. Larger packets may make it easier to cause some forms of denial of service due to fragment loss. Donald E. Eastlake, 3rd [Page 5]
INTERNET-DRAFT Bigger 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 August 1998. Its file name is draft-ietf-dnsind-udp-size-01.txt. Donald E. Eastlake, 3rd [Page 6]
