Mark Andrews (CSIRO) INTERNET-DRAFT Paul Vixie (ISC) <draft-andrews-dns-more-00.txt> June 1996 Amends: RFC 1035 Large Responses to DNS Queries (DNS MORE) Status of This Memo 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 and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract DNS messages are limited to 64 kilobytes in size. At times it is necessary to send a message that is greater that 64 kilobytes. This is currently not possible. AXFR is the one exception. This document describes how to send a sequence of messages, the total length which may be greater than 64 kilobytes, by extending the protocol. In addition average message sizes are increasing and the 512 byte payload limit for UDP is now too small. This document describes how servers can identify when they can send bigger messages without necessarily resorting to TCP. Expires December 1996 [Page 1]
INTERNET-DRAFT DNS MORE June 1996 1 - Protocol This extension uses one of the RESERVED flags bits from DNS header [RFC1035 4.1.1] to indicate when a message is one of a sequence of mes- sages. This flag bit shall be known as MORE. The MORE flag's semantics depend upon the underlying transport protocol. This document only defines the use of the MORE flag with the opcode QUERY. 1.1 - TCP Usage When using TCP a resolver sets the MORE flag to indicate that it is capable of receiving a multi message response (which we call a ``message sequence''). To indicate that the message sequence is not complete, the server inserts an additional record with name = QNAME, class = QCLASS, TTL = 0, type = ANY and dlen = 0, in all but the last message of the sequence. This record shall be known as the Message Continuation Indicator (MCI RR). The order of resource records in a multi message response MUST be the same as if the response could have been sent is a single response, after the MCI RR has been removed. Each message in a sequence will contain a header with the same ID value, flags, opcode and response code. Only the count fields are permitted to change. The counts shall represent the number of resource records in this message. TC MUST be set, and MORE cleared in the response. 1.2 - UDP Usage When using UDP, a resolver may set the MORE flag in a QUERY request to indicate that its receive buffer is 8192 bytes in size, rather than the 512 byte size given in [RFC1035 3.2.4]. The resolver is expected to set this flag only if it knows that the host's reassembly buffer is large enough to accomadate datagrams of that size. A server receiving a QUERY request with the MORE flag set is allowed to transmit a response of up to 8192 bytes. If the response will not fit in 8192 bytes, then the rules given in [RFC1035 4.1.1, 4.2.1, 6.2] apply. Expires December 1996 [Page 2]
INTERNET-DRAFT DNS MORE June 1996 The server MUST clear the MORE flag in the response. The server SHOULD disable path MTU discovery on the UDP response packet resulting in host fragmentation. 2 - Header Format The header format is that described in [RFC1035 4.1.1] with the MORE flag added: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA|MO| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Where MO is the MORE flag. 3 - Security Considerations Though DNS is related to several security problems, no attempt is made to fix them in this document. This document is believed to introduce no additional security problems to the current DNS protocol. Expires December 1996 [Page 3]
INTERNET-DRAFT DNS MORE June 1996 References [RFC1035]P. Mockapetris, ``Domain Names - Implementation and Specifica- tion,'' RFC 1035, USC/Information Sciences Institute, November 1987. Authors' Addresses Mark Andrews CSIRO - Division of Mathematics and Statistics Locked Bag 17 North Ryde NSW 2113 AUSTRALIA +61 2 325 3148 <Mark.Andrews@dms.csiro.au> Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 USA +1 415 747 0204 <paul@vix.com> Expires December 1996 [Page 4]