start of the DNS Message, which can be 64KB in length. 14 bits restrict
pointers to the first 16KB of the message, which makes labels introduced
in the last 48KB of the message unreachable by compression pointers. A
longer pointer format is needed.
2.2. DNS Messages are limited to 65535 octets in size when sent over
TCP. This acts as an effective maximum on RRset size, since multiple
TCP messages are only possible in the case of zone transfers. Some
mechanism must be created to allow normal DNS responses (other than zone
transfers) to span multiple DNS Messages when TCP is used.
2.3. Multiple queries in a question section have not been supported in
DNS due the applicability of some DNS Message Header flags (such as AA)
and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
Multiple questions per request are desirable, and some way of asking
them must be made available.
3.1. In [EDNS0], the ``0 1'' label type was specified to denote an
extended label type, whose value is encoded in the lower six bits of the
first octet of a label, and an extended label type of ``1 1 1 1 1 1''
was further reserved for use in future multibyte extended label types.
3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended
compression pointer, such that the following two octets comprise a
16-bit compression pointer in network byte order. Like the normal
compression pointer, this pointer is relative to the start of the DNS
3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit
string label as described in [CRAW98].
3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
local compression pointer'' as described in [KOCH98].
Expires December 1999 [Page 2]
INTERNET-DRAFT EDNS1 June 1999
4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
are structured as follows:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As
VERSION Indicates the implementation level of whoever sets it.
Full conformance with the draft standard version of this
specification is version ``1.'' Note that both
requestors and responders should set this to the highest
level they implement, that responders should send back
RCODE=BADVERS and that requestors should be prepared to
probe using lower version numbers if they receive an
MD ``More data'' flag. Valid only in TCP streams where
message ordering and reliability are guaranteed. This
flag indicates that the current message is not the
complete request or response, and should be aggregated
with the following message(s) before being considered
complete. Such messages are called ``segmented.'' It
is an error for the RCODE (including the EXTENDED-
RCODE), AA flag, or DNS Message ID to differ among
segments of a segmented message. It is an error for TC
to be set on any message of a segmented message. Any
given RR must fit completely within a message, and all
messages will both begin and end on RR boundaries. Each
section in a multipart message must appear in normal
message order, and each section must be complete before
later sections are added. All segments of a message
must be transmitted contiguously, without interleaving
FM ``First match'' flag. Notable only when multiple
questions are present. If set in a request, questions
will be processed in wire order and the first question
whose answer would have NOERROR AND ANCOUNT>0 is treated
Expires December 1999 [Page 3]
INTERNET-DRAFT EDNS1 June 1999
as if it were the only question in the query message.
Otherwise, questions can be processed in any order and
all possible answer records will be included in the
response. Response FM should be ignored by requestors.
RRD ``Recursion really desired'' flag. Notable only when a
request is processed by an intermediate name server
(``forwarder'') who is not authoritative for the zone
containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If
set in a request, the intermediate name server can only
answer using unexpired cached answers (either positive
or negative) which were atomically acquired using (a)
the same QTYPE or set of QTYPEs present in the current
question and whose TTLs were each minimized to the
smallest among them when first cached, and (b) the same
FM and LM settings present in the current question.
LM ``Longest match'' flag. If this flag is present in a
query message, then for any question whose QNAME is not
fully matched by zone or cache data, the longest
trailing label-bounded suffix of the QNAME for which
zone or cache data is present will be eligible for use
as an answer. Note that an intervening wildcard name
shall supercede this behaviour and the rules described
in [RFC1034 4.3.2, 4.3.3] shall apply, except that the
owner name of the answer will be the wildcard name
rather than the QNAME. Any of: QTYPE=ANY, or
QCLASS=ANY, or QCOUNT>1, shall be considered an error if
If LM is set in a request, then LM has meaning in the
response as follows: If the content of the response
would have been different without the LM flag being set
on the request, then the response LM will be set; If the
content of the response was not determined or affected
by the request LM, then the response LM will be cleared.
If the request LM was not set, then the response LM is
not meaningful and should be set to zero by responders
and ignored by requestors.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
Expires December 1999 [Page 4]
INTERNET-DRAFT EDNS1 June 1999
5 - Multiple Questions for QUERY
5.1. If QDCOUNT>1, multiple questions are present. All questions must
be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
5.2. RCODE and AA apply to all RRs in the answer section having the
QNAME that is shared by all questions in the question section. AA
applies to all matching answers, and will not be set unless the exact
original request was processed by an authoritative server and the
response forwarded in its entirety.
5.3. If a multiple question request is processed by an intermediate
server and the authority server does not support multiple questions, the
intermediate server must generate an answer iteratively by making
multiple requests of the authority server. In this case, AA must never
be set in the final answer due to lack of atomicity of the contributing
5.4. If iteratively processing a multiple question request using an
authority server which can only process single question requests, if any
contributing request generates a SERVFAIL response, then the final
response's RCODE should be SERVFAIL.
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton,
and Michael Graff were each instrumental in creating this specification.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Institute, November 1987.
[EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft
draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998
[CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,''
Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March
[KOCH98] P. Koch, ``A New Scheme for the Compression of Domain
Expires December 1999 [Page 5]
INTERNET-DRAFT EDNS1 June 1999
Internet Software Consortium
Expires December 1999 [Page 6]