Subject: Re: draft-dnsext-edns1-04.txt

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Aug 2002 01:28:04 +0000

> >    FM       ``First match'' flag.  Notable only when multiple questions are
> >             present.  If set in a request,
> 
> nit, "enabled" is more accurate than "set". Flags/bits can be set on and
> off, but they can only be enabled or disabled.

other dns rfc's have used set and clear, so i'll stick with that naming.

> >             included in the response.  Response FM should be ignored by
> >             requestors.
> 
> Is there a reason you don't say that servers MUST echo the flag setting
> received in the query? If so, shouldn't this say that clients MUST ignore
> the setting?

this was fixed in the diffs sent around yesterday.

> >    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.
> 
> This needs clarifying. From what I read, a query for MX+A+AAAA with RRD
> enabled would require that the server only answer the query if each of
> those RRtypes had been queried distinctly.
> 
> However, I don't see how this plays into the QTYPE=ANY statement. If the
> server queried for QTYPE=ANY and got an incomplete answer from its
> upstream (such as a slave forwarder asking its daddy cache), then the
> conditions would be satisfied, and the slave could return the same
> incomplete answer set.

that's what happens in the QDCOUNT=1 case, so, we're simply specifying that
that has not changed in the QDCOUNT>1 case.

> I think it might be safest to just say that RRD has
> no meaning in a response for QTYPE=ANY unless AA is also enabled.

AA in queries isn't meaningful (even though BIND defines RES_AAONLY).

> Also, the motivation for the synchronized TTLs "when first cached" isn't
> obvious to me. What do you mean by that, and can you say what you mean in
> such a way that I understand why?

the key word is "atomically."  but i agree that trying to salvage any meaning
for QTYPE=ANY is probably doomed at this late date, particularly in the case
where the EDNS1->!EDNS gateway must speak through a forwarder rather than to
the authority servers directly.  i'll remove the QTYPE=ANY wording, since it
was a debugging wish rather than an operational expectation.

> >    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.
> 
> If you can't indicate unique errors in the answers, MUST be SERVFAIL

fixed.

> >    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.
> 
> What does a cache do?

a cache would not respond with a referral so they aren't mentioned here.

> >    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.
> 
> q1 may be a negative answer and q2 may not be available (RA=0). There
> would not be any answer data so this logic doesn't work in that scenario.
> 
> I don't see a discussion on NODATA processing when it applies to ALL of
> the questions.
> 
> No mention of RA=0 here.

if RA=0 then you should only be going to this server for authoritative
answers, in which case none of this except 4.6 applies in any case.

> No mention of truncation either. If the TC bit is enabled, this rule does
> not apply.

i do not think it's nec'y to respecify TC handling; rfc1035 does a fine job.

> How does this rule apply when one of the multipart questions was for
> CNAME, but the only available answer is a CNAME (no recursion performed).

since it is an error for there to be any other RR present at a node if there
is a CNAME present at that node, this condition cannot occur.

> General comments
> 
> Might want to include a disclaimer that this specifically does not apply
> to Dynamic DNS.

dynamic dns specifies its own definition for the field variable occupied
by "QDCOUNT".  i think i won't mention that it's unaffected by this proposal.

more later.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Aug 2002 04:16:59 +0000

> ... This simple comparison would give a general ratio which could be
> used to perform some minimal projections, that N% of queries were
> forwarded from a cached referral, while the remainder were not.
> 
> Is this kind of detail available?

from some of the root servers but probably not from all of them.
note that some of the roots servers are also authoritative for some
tld's (.edu and .mil are examples) and in this case a referral from
the "root" will actually be to a second level name rather than a tld.
(i mention this only to avoid evaluating skewed data.)

i suspect that verisign would treat this as proprietary data about
.com, net, and .org, which are the busiest tld's.  you might be
able to get some tld operator to go along but i can't think of one
that's both (likely AND useful).

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Aug 2002 14:46:00 -0700

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> Well-know fact that excess RRs bound to an owner will cause
    Eric> overflow of UDP queries for qtype ALL.

This is a DNS administration issue rather than one about protocol
design. Adding more record types to an owner name just gives a longer
piece of rope to the less clueful. And they can already hang themselves
without introducing new record types. So why hold back DNS progress --
if that's what putting keys into the DNS is -- because it might make
naive users do stupid or bad things? It's not as if stupid and bad DNS
configurations are an unheard of phenomona today.

    Eric> Adding "just one more" RR to a set means that all first-pass
    Eric> queries for an overloaded owner name fail. Less useful.

Maybe. But probably not an issue if EDNS0 was widely deployed. And
anyway RFC3225 can be summarised as "use EDNS0 if you want to get
crypto gunk from a name server". Another one -- RFC3226 -- says "use
EDNS0 with certain UDP buffer sizes if you expect to get A6 and binary
labels (may they rest in peace) in the answer". Spot a trend here?

And let's not forget that caching will alleviate the impact of any
truncation. Sure, my server might get truncation when fetching signed
MX records for aol.com (say). But for one lookup per TTL interval to
aol.com's name servers. My mail systems will get truncation when they
repeat that query to my local cache, but that's no big deal: they
won't be beating up the aol.com name servers with those queries.

    Eric> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. 

Sorry, I just don't understand this. When did TCP (or name servers)
have a problem transferring more than a few Kb?

    Eric> Cache overflow is already common in large ISPs. Less useful.

I'm not sure I know what you mean by "cache overflow". Presumably it
is some condition that means truncated responses. If so, how much of
that would go away if EDNS0 was more widespread? If this is as much of
a problem today as you suggest, have you any numbers to support this
claim? Does anyone have name servers that are *really* suffering
because of truncated responses and TCP retries? And what percentage of
them have a genuine need to truncate responses as opposed to
truncating because of hostmaster silliness?

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Aug 2002 15:19:22 -0700

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> My message was meant to suggest that we should be working on
    Eric> those alternatives so that there is somewhere else to put
    Eric> this stuff.

Well I fail to see how you can advance that position by making
non-sequiturs about TCP window and cache sizes.

    Eric> Adding a bunch of 4k RRs to an owner can exceed TCP
    Eric> capacity.
    >>  Sorry, I just don't understand this. When did TCP (or name
    >> servers) have a problem transferring more than a few Kb?

    Eric> The TCP size field is a 16-bit value, meaning that a message
    Eric> has a maximum capacity of 64k.

And the point you are making here is.....? Apart from needing some
extra TCP headers, how would shifting more than 64k of data present a
problem? [BTW it's the window size that has a 16-bit value in TCP.
This has nothing to do with message size: a nebulous concept in a byte
stream protocol like TCP.] And anyway, doesn't the TCP window scale
option allow for *much* bigger windows than 64k?

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Aug 2002 15:29:32 -0700

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> What I'm saying is (d) the more crap we stick into DNS, the
    Eric> more caches will overflow, making the service less useful

This doesn't make sense. Cached data clearly must be of some use
because it's being cached. And if someone's cache overflows, where's
the problem? There are various well known and widely implemented
solutions for this. Like buying more RAM (at how many cents/Mb?) or
adding more caching name servers. Or have the name server discard
older data to make room for the newer stuff.

Even if caches overflow and servers die horrible deaths as a result
of caching too much data, this only matters if it generates excessive
DNS traffic or causes unbearably long lookup latencies. And once again
this would be an administration/engineering problem, not one of protocol
design.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Aug 2002 16:44:47 +0000

> 	Title		: The ADDR DNS Query-Type

please don't.

when rfc1886 was proposed, several of us strongly recommended that "A" RR's
be included as additional data when a "AAAA" query was answered.  in the
same way and for the same reason as we include "A"'s in the additional data
section when answering "MX" or "NS" queries.

we were shot down.  the reason given was "this is only useful during the
transition period to V6, after which it's wasted complexity and wasted
bandwidth."

if you want this functionality, you'll have to answer that objection.
(my answer to this objection was EDNS's ability to ask multiple questions
in a single query, but this was shot down for a separate set of reasons.)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Aug 2002 17:10:08 +0000

> I would agree with that assessment. The argument doesn't apply when it has
> been explicitly requested, however.

your proposal makes the request implicit, and runs afoul of the same "this
will still be in use long after the v4->v6 transition is over" problem.  if
we're going to pay in complexity for something like ADDR, then let's pay the
same price but get something way more general.  below, see EDNS1 (expired),
and note that we could very easily excerpt just the parts that deal with
multiple questions in a query and push the rest of the swill into EDNS2 (as
was already done when the original EDNS proposal was split into EDNS0/EDNS1):

--------

   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]


--------

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Aug 2002 01:17:06 +0000

> > if we're going to pay in complexity for something like ADDR, then let's
> > pay the same price but get something way more general. below, see EDNS1
> > (expired), and note that we could very easily excerpt just the parts
> > that deal with multiple questions in a query
> 
> > ...
> This needs a lot more discussion and fleshing out.

i've been waiting several years got someone to discuss this with.  thank you!

> Are partial answers acceptable (as with a cache that has temporarily
> lost external connectivity)?

this depends on the setting of RRD and whether iteration is being done.  if
iteration is being done because the authority server is known not to handle
QDCOUNT>1, then any SERVFAIL causes the underlying QDCOUNT>1 question to be
answered with SERVFAIL.  temporary loss of connectivity signals SERVFAIL.

(i consider the document to already be clear on this point.)

> Is it possible to indicate positive answers, NODATA

yes.  if you get some answer RR's matching some of the QTYPEs but no RR's
matching one or more of the QTYPEs then you know the missing ones are NODATA.

(i will upgrade the wording on this point.)

> and referrals in the same message?

no.  if there are NS RR's then there will be a referral, no matter what other
RR's are also present.  if there are no NS RR's then the answer will not be
a referral, no matter what RR types are present and what QTYPEs are present.

(i will upgrade the wording on this point.)

> How would the "recursion really desired" flag interact with all of this?

only in regards to yout first question above ("partial answers acceptable?")

> In general, I think it is a good idea, but I'm not completely convinced
> that it's possible. It is not nearly as simple as QTYPEADDR, but it
> certainly does offer longer term rewards due to its generalized nature, if
> it is feasible at all.

i'll take that as an invitation to split EDNS1-old into EDNS1-current and
EDNS2-current, where EDNS2-current will be all the stuff in EDNS1-old that's
not directly competitive to QTYPE=ADDR.  (that's how EDNS0 was born and EDNS1
was shelved... but then there was EDNS0.5, appears to be on track to /dev/null)

(done.  updated EDNS1 and EDNS2 are about to be sent to the drafts editor.)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Aug 2002 06:31:59 +0000

> Here is the scenario I want to trip:
> 
>   client asks for A, AAAA and MX
>   server has A cached
>   server has AAAA NODATA cached
>   server has no information about MX and can't/won't go get it
> 
> It is possible that the server would have learned A and AAAA through some
> other means (such as glue data, although this doesn't really work with the
> NODATA part), while also refusing to fetch the MX RR.

first off, the promiscuous-cache model practiced by bind4/bind8 is *wrong*,
and glue should not be generally cached nor ever upgraded to an answer.  glue
is like the evil slime that sticks to your shoes in a movie theater, and
should only be reused if to satisfy requirements for additional data during
the marshalling of an answer to the same query whose original forwarding
caused that glue to be received in the first place.

that's not germane to the subject, but i didn't want to let the moment pass.

second, if the client can't or won't go get it, that means the response to a
normal query (QDCOUNT=1, QTYPE=MX) would be SERVFAIL, which according to both
the old (1999) and new (today) EDNS1 documents, would cause SERVFAIL to be
signalled to the QDCOUNT>1 requestor.  so in order to go deeper on this one,
you'll have to explain what you mean, exactly, by "can't" and/or "won't".

> Signalling the difference between NODATA and referral is pretty difficult,
> since the client would interpret the referral as being applicable to both
> AAAA and MX equally. This may be okay, since the only likely harm would be
> a larger followup question. Tell me it's okay.

it's ok, but not for that reason.  a referral can only come from an authority
server.  the section of the document you are worrying about is talking about
intermediate recursive/caching servers ("full resolvers" in RFC1035 lingo.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Aug 2002 16:31:54 +0000

> [EDNS1] doesn't currently address the weird scenarios that can occur
> from multiple answer types within a single message so I don't think
> it's viable in it's current form.

I thought that I had addressed your concerns in the rerelease of EDNS1
("August 2002" version) but I stand ready to make any further corrections.
Please let me know what clarifications or changes you think are needed.

Since it's only four pages I will include it here.  Note that this shows
one correction received privately, which was that I hadn't updated the
flags picture to account for the DO bit.  I've also reset the draft name
as directed by the drafts editor.

--------

   DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-ietf-dnsext-edns1-03.txt>                           August, 2002

   Status of this Memo

   Abstract

      This document specifies an extension within the Extended DNS
      framework defined by [RFC2671], providing the ability to ask multiple
      questions in a single request.

   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.1. Multiple queries in a question section have not been supported in

   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: |do |FM |RRD|                         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
            requestors.

   Expires March 2003                                              [Page 2]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   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

   4.3. If a multiple question request is processed by an intermediate

   Expires March 2003                                              [Page 3]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   5 - References

   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998

   6 - Author's Address

                 Paul Vixie
                    +1.650.779.7001
                    <[email-masked]>

   Expires March 2003                                              [Page 4]

--------

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Aug 2002 21:13:14 +0000

> ... For any situation where multiple types of answers can be returned
> (with any level of feasibility), the handling of those commingled
> answer types needs to be described.

please quote the unclear portion of the document and suggest an improvement.

> Some additional discussion on retry techniques, incomplete cache sets and
> so forth would also be nice. When a cache needs to fetch missing answers,
> what are the requirements or issues with coordinating TTLs among the
> answers, or answer types, for example.

that's all covered in the current document, as far as i can see.  could we
hear additional voices, since eric and i appear to be at a dead end here?

> It's just too vague for my liking. This is untested waters and it really
> should be fleshed out, overspecified even, to offset the worries.

one of the things mr. bush tried to tell me during the preparation of 1996
and 2136 was that if you include a lot of tutorial jazz you run the risk of
having your document disagree with itself.  minimalism is best in the core
specification.  if you think a companion document which explains the model
but specifies nothing in and of itself is appropriate, then please write it.