One document matched: draft-ietf-dnsind-udp-size-00.txt

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]