DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-ietf-dnsext-edns1-03.txt>                           August, 2002
                          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-
      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
      The list of Internet-Draft Shadow Directories can be accessed at
      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
   1 - Rationale and Scope
   1.1. EDNS (see [RFC2671]) 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 the
   ability to ask multiple questions in a single request.
   Expires March 2003                                              [Page 1]

   INTERNET-DRAFT                    EDNS1                     August, 2002
   2 - Affected Protocol Elements
   2.1. 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 - OPT pseudo-RR Flags and Options
   3.1. The extended RCODE and flags are structured as follows:
                    +0 (MSB)                            +1 (LSB)
      0: |         extended-rcode        |            VERSION            |
      2: |md |FM |RRD|lm |                       z                       |
   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.
   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 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
   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
   Expires March 2003                                              [Page 2]

   INTERNET-DRAFT                    EDNS1                     August, 2002
            smallest among them when first cached, and (b) the same FM and
            LM settings present in the current question.
   Z        Set to zero by senders and ignored by receivers, unless
            modified in a subsequent specification.
   4 - Multiple Questions for QUERY
   4.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.
   4.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.
   4.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.
   4.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.
   4.5. An authority server processing a query for which QDCOUNT>1 will
   respond with a delegation or referral if any of the multiple QTYPEs
   present would yield such a response when QDCOUNT==1.
   4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
   where QDCOUNT>1 if the response contains no RRs of that type but some
   RRs for one of the other QTYPEs present.
   Expires March 2003                                              [Page 3]

   INTERNET-DRAFT                    EDNS1                     August, 2002
   5 - References
   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.
   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998
   6 - Author's Address
                 Paul Vixie
                    Internet Software Consortium
                    950 Charter Street
                    Redwood City, CA 94063
   Expires March 2003                                              [Page 4]