< draft-andrews-dns-more-00.txt		draft-andrews-dns-more-01.txt >
	Mark Andrews (CSIRO)		Mark Andrews (CSIRO)
	INTERNET-DRAFT Paul Vixie (ISC)		INTERNET-DRAFT Paul Vixie (ISC)
	<draft-andrews-dns-more-00.txt> June 1996		<draft-andrews-dns-more-01.txt> June 1996
	Amends: RFC 1035		Updates: RFC 1035
	Large Responses to DNS Queries (DNS MORE)		Large Responses to DNS Queries (DNS MORE)
	Status of This Memo		Status of This Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its		documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	DNS messages are limited to 64 kilobytes in size. At times it is		DNS messages are limited to 64 kilobytes in size. At times it is
	necessary to send a message that is greater that 64 kilobytes.		necessary to send a message that is greater that 64 kilobytes.
	This is currently not possible. AXFR is the one exception. This		This is currently not possible. AXFR is the one exception. This
	document describes how to send a sequence of messages, the total		document describes how to send a sequence of messages, the total
	length which may be greater than 64 kilobytes, by extending the		length which may be greater than 64 kilobytes, by extending the
	protocol.		protocol.
	In addition average message sizes are increasing and the 512		In addition average message sizes are increasing and the 512
	byte payload limit for UDP is now too small. This document		byte payload limit for UDP is now too small. This document
	describes how servers can identify when they can send		describes how servers can identify when they can send bigger
	bigger messages without necessarily resorting to TCP.		messages without necessarily resorting to TCP.
	1 - Protocol		1 - Protocol
	This extension uses one of the RESERVED flags bits from DNS header		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-		[RFC1035 4.1.1] to indicate when a server can send the extended
	sages. This flag bit shall be known as MORE.		response. This flag bit shall be known as MORE.
	The MORE flag's semantics depend upon the underlying transport protocol.		The MORE flag's semantics depend upon the underlying transport protocol.
	This document only defines the use of the MORE flag with the opcode		This document only defines the use of the MORE flag with the opcode
	QUERY.		QUERY.
	1.1 - TCP Usage		1.1 - TCP Usage
	When using TCP a resolver sets the MORE flag to indicate that it is		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		capable of receiving a multi message response (which we call a ``message
	sequence'').		sequence'').
	To indicate that the message sequence is not complete, the server		To indicate that the message sequence is not complete the server shall
	inserts an additional record with name = QNAME, class = QCLASS, TTL = 0,		set the RCODE to CONTINUED (TBA) in all but the last message of the mes-
	type = ANY and dlen = 0, in all but the last message of the sequence.		sage 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		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		same as if the response could have been sent is a single response. The
	the MCI RR has been removed.		Questions first followed by, the Answer RRs, Authority RRs and Addi-
			tional RRs.
	Each message in a sequence will contain a header with the same ID value,		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		flags, opcode. Only the count fields and the rcode are permitted to
	change. The counts shall represent the number of resource records in		change. The counts shall represent the number of resource records in
	this message. TC MUST be set, and MORE cleared in the response.		this message. MORE MUST cleared in the response.
			1.1.1 - TCP Example
			The following example show how to send an answer with one question, 10
			answer records, 14 authority records and 5 additional records. The
			answer is split up across 3 messages.
			MESSAGE 1: QCOUNT=1, ANCOUNT=10, AUCOUNT=0,
			ADCOUNT=0, RCODE=CONTINUED
			MESSAGE 2: QCOUNT=0, ANCOUNT=0, AUCOUNT=11,
			ADCOUNT=0. RCODE=CONTINUED
			MESSAGE 3: QCOUNT=0, ANCOUNT=0, AUCOUNT=3,
			ADCOUNT=5, RCODE=NOERROR
	1.2 - UDP Usage		1.2 - UDP Usage
	When using UDP, a resolver may set the MORE flag in a QUERY request to		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		indicate that its receive buffer is greater than 512 bytes in size,
	512 byte size given in [RFC1035 3.2.4]. The resolver is expected to set		rather than the 512 byte size given in [RFC1035 3.2.4]. The resolver is
	this flag only if it knows that the host's reassembly buffer is large		expected to set this flag only if it knows that the host's reassembly
	enough to accomadate datagrams of that size.		buffer is large enough to accommodate datagrams of the size indicated.
			The new size is indicated by the RCODE is the query. The receive buffer
			is 512 * (2 ^ RCODE) bytes in size.
			RCODE SIZE
			0 512
			1 1024
			2 2048
			3 4096
			4 8192
			5 16384
			6 32768
			7 65536
			8 131072
			9 262144
			10 524288
			11 1048576
			12 2097152
			13 4194304
			14 8388608
			15 16777216
	A server receiving a QUERY request with the MORE flag set is allowed to		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		transmit a response of up to the size indicated. If the response will
	in 8192 bytes, then the rules given in [RFC1035 4.1.1, 4.2.1, 6.2]		not fit in size indicated, then the rules given in [RFC1035 4.1.1,
	apply.		4.2.1, 6.2] apply.
	The server MUST clear the MORE flag in the response.		The server MUST clear the MORE flag in the response.
	The server SHOULD disable path MTU discovery on the UDP response packet		The server SHOULD disable path MTU discovery on the UDP response packet
	resulting in host fragmentation.		resulting in host fragmentation.
	2 - Header Format		2 - Header Format
	The header format is that described in [RFC1035 4.1.1] with the MORE		The header format is that described in [RFC1035 4.1.1] with the MORE
	flag added:		flag added:
End of changes. 10 change blocks.
	22 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/