250 lines
12 KiB
Plaintext
250 lines
12 KiB
Plaintext
DNSIND Working Group Paul Vixie
|
|
INTERNET-DRAFT ISC
|
|
<draft-ietf-dnsind-edns1-03.txt> June, 1999
|
|
|
|
Extensions to DNS (EDNS1)
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
|
all provisions of Section 10 of RFC2026.
|
|
|
|
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 documents at any
|
|
time. It is inappropriate to use Internet-Drafts as reference
|
|
material or to cite them other than as "work in progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
Abstract
|
|
|
|
This document specifies a number of extensions within the Extended
|
|
DNS framework defined by [EDNS0], including several new extended
|
|
label types and the ability to ask multiple questions in a single
|
|
request.
|
|
|
|
1 - Rationale and Scope
|
|
|
|
1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see
|
|
[RFC1035]) which provides for larger message sizes, additional label
|
|
types, and new message flags.
|
|
|
|
1.2. This document makes use of the EDNS extension mechanisms to add
|
|
several new extended label types and message options, and the ability to
|
|
ask multiple questions in a single request.
|
|
|
|
Expires December 1999 [Page 1]
|
|
|
|
INTERNET-DRAFT EDNS1 June 1999
|
|
|
|
2 - Affected Protocol Elements
|
|
|
|
2.1. Compression pointers are 14 bits in size and are relative to the
|
|
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 - Extended Label Types
|
|
|
|
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
|
|
Message.
|
|
|
|
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 (MSB) +1 (LSB)
|
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
|
0: | EXTENDED-RCODE | VERSION |
|
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
|
2: |MD |FM |RRD|LM | Z |
|
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
|
|
|
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As
|
|
defined by [EDNS0].)
|
|
|
|
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
|
|
RCODE=BADVERS.
|
|
|
|
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
|
|
of other messages.
|
|
|
|
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
|
|
the LM flag is set.
|
|
|
|
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
|
|
authoritative responses.
|
|
|
|
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.
|
|
|
|
6 - Acknowledgements
|
|
|
|
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.
|
|
|
|
7 - References
|
|
|
|
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
|
|
Specification,'' RFC 1035, USC/Information Sciences
|
|
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
|
|
1998.
|
|
|
|
[KOCH98] P. Koch, ``A New Scheme for the Compression of Domain
|
|
Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.
|
|
|
|
Expires December 1999 [Page 5]
|
|
|
|
INTERNET-DRAFT EDNS1 June 1999
|
|
|
|
IETF DNSIND, March 1998.
|
|
|
|
8 - Author's Address
|
|
|
|
Paul Vixie
|
|
Internet Software Consortium
|
|
950 Charter Street
|
|
Redwood City, CA 94063
|
|
+1 650 779 7001
|
|
<vixie@isc.org>
|
|
|
|
Expires December 1999 [Page 6]
|