--- /dev/null
+ 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]
git.samba.org / tridge / bind9.git / blobdiff