Subject: EDNS1

From: Paul A Vixie <[email-masked]>
Date: Tue, 09 Oct 2001 09:19:37 -0700

several folks in the last few weeks have asked me about EDNS1 and so i'd
like to revive the draft and give it the discussion (and/or decent burial)
that it needs.  here's the last published version, which i'd like to hear
some comments about so i can improve it (somehow?) and officially resubmit.

   DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-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
                    <[email-masked]>

   Expires December 1999                                           [Page 6]


to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Robert Elz <[email-masked]>
Date: Wed, 10 Oct 2001 11:48:07 +0700

Date:        Tue, 09 Oct 2001 09:19:37 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  |    2 - Affected Protocol Elements

I'd like to see ...

    2.4.  Only a subset of DNS RR types support compression of labels in
    the RDATA, as explained in [...whatever that new draft is...].  Where
    it is known that the requestor, and the server, both recognise other
    RR types, and so can locate labels in the RDATA, and decompress them,
    name compression can be permitted in the RDATA of additional RR types.

added, and then:

  |    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 |XC |                   Z                       |
  |          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  | 
       XC		If set to 1 by the sender, then the sender understands
			label compression in the extended set of RR types as
			defined for the VERSION specified.   If set to 1 in
			a response, the server indicates that it is able to
			compress labels for the extended set of RR types as
			defined for the VERSION specified.   Any label
			compression scheme defined by the DNS for the EDNS
			VERSION agreed between sender and responder may be used.

and then add a new section (6) below (and renumber those that were 6, 7, 8
into 7, 8, 9, of course)

    6.  Extended Label Compression RDATA RR types

	Any DNS system that supports extended compression (sets the XC
	bit in the OPT RR) and supports EDNS version 1, must support
	label compression in all domain names included in the RDATA of
	the followingRR types, as well as all of those defined by RFC1035.

	NXT (rfc2535) SRV (rfc2782) A6 (rfc2874) TKEY (rfc2930)
	NAPTR (rfc2915) TSIG (rfc2845) DNAME (rfc2672) KX (rfc2230)
	PX (rfc2163) AFSDB (rfc1183) RP (rfc1183)

(OK, including the algorithm "domain name" from TKEY and TSIG might
be going a bit overboard, deleting those from this list wouldn't harm
a lot I don't think).

If I missed any that should be added, then add them...  (if any of those
I found are so obsolete that no-one will ever use them, then we should
drop them from the list, so as to avoid requiring people to support rubbish).

I know NXT allows compression anyway, according to 2535 anyway, though
I'm not sure that is really appropriate ... it is intended to only be used
between servers that understand it, but I'm not sure how that is actually
enforced.   In any case, explicitly specifying it to be OK for EDNS1 can't
hurt.

(continuing the above section to be inserted...)

	A DNS server capable of compressing the domain labels in the
	RDATA of all of the RR types listed above (plus all of the
	RR types defined to support compression in rfc1035) MAY set the
	XC bit in the OPT RR in responses it sends that include that RR,
	where the version indicated as supported is 1.   If support for
	a higher version number is available, the XC bit MUST NOT be set
	in responses unless any additional RRs defined for that EDNS
	version are also supported.

	In any case, a server MUST NOT compress labels for any of the above
	RR types, unless it is responding to a query received containing an
	OPT RR with the XC bit set, and a version of at least 1.
	When responding to a query wich was received with the XC bit set
	in an included OPT RR which has a version of 1 or greater, the
	server MAY compress labels in the above RR formats using any
	compression scheme available to be used in the EDNS version applicable.

	Domain names in the RDATA field of RR types not listed here, or in
	rfc1035, or in the specification of some later EDNS version agreed
	between sender and server, MUST NOT be compressed.

Aside from that, I'd fix ...

  |    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.

to be
	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 only a SERVFAIL response, then the final
	response's RCODE should be SERVFAIL.

That is, if there are 2 auth servers listed for a QNAME, the intermediate
server tries one, and gets SERVFAIL, but then tries the other, and gets all
the answers it needs, it shouldn't be setting SERVFAIL in the response, only
if it is unable to get an answer to one of the questions from any of the
auth servers for the QNAME (that it chooses to try).

  |    7 - References

Most of the ones in this list that were drafts are RFCs now...

except ...

  |    [KOCH98]   P. Koch, ``A New Scheme for the Compression of Domain
  |               Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.

which seems to have vanished completely.  If it isn't coming back, the
reference, and the label code tentatively allocated for it, need to go
as well.

kre

---

From: Paul Vixie <[email-masked]>
Date: 11 Oct 2001 09:48:23 -0700

so far in response to my reposting of the 1999 EDNS1 draft i've seen:

	1. several requests to kill it

	2. one statement (from a WG cochair) indicating that it was already
	dead, was nonrevivable, and that DNS-NG was the next great thing

	3. one request to attach a rider based on the current compression
	debate

every feature in the 1999 draft was topical at the time it was released, but
may be less so now.  if we've moved on and don't need any of that stuff then
there's no reason to revive it.

unless someone publically indicates support for any of the features described
in the 1999 EDNS1 draft, i'm going to move it to historic, i.e., kill it.

the thing that would surprise me is if noone in the IPv6 arena wanted to be
able to ask multiple questions in the same query, for AAAA and A.  (if A6
dies, then QDCOUNT>1 would be a performance win for an AAAA world.)