Subject: draft-dnsext-edns1-04.txt

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

DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-dnsext-edns1-04.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-
      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 [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
            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

   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
                    +1.650.779.7001
                    <[email-masked]>

   Expires March 2003                                              [Page 4]


--
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: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Aug 2002 03:27:42 -0500

[late-night comments in-line and at bottom]

>    them must be made available.

Multiple questions is easy. Multiple answers is the hard part.

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

> questions will be processed in

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?

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

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?

>    response's RCODE should be SERVFAIL.

If you can't indicate unique errors in the answers, MUST be SERVFAIL

>    present would yield such a response when QDCOUNT==1.

What does a cache do?

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

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

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

General comments

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

Nowhere do you describe the behavior of caches here. Do they always relay
the query and then return the answer (or the error) to the resolver
unmolested? Are they allowed to intercept errors and try to complete the
query using distinct qtypes if feasible. What kind of knowledge is
required for this (eg, based on existing round-trip timers, the cache
would be able to fill in the holes before a timer expired)? Or should
caches simply default to respond with just the cached data. I assume that
RRD is meant to do something here but I can't quite figure out what caches
are supposed to do about incomplete answer sets when RD and/or RRD. Or
when RD and RRD are mixed, for that matter. How smart should caches try to
be?, that is the unanswered question.

If it were me, I would make some discussion about how resolvers need to
support whatever model gets used here, too. Are there specific timer
requirements, specific fallback behaviors, and so forth. Somebody has to
perform fallback processing, and it will always be a resolver at some
point in time. I assume your expectation is that the EDNS 0.5 mechanisms
will be used here although I would make that discussion clear WRT the
issues with multiple questions in particular.

You don't describe TTL synchronization issues. Should all of the RRsets be
treated as a superset and therefore be synchronized? What ramifications
does this have for different synchronizations? For example, there might be
an NS pointing to an AAAA and an MX pointing to an A, both of which have
their own synchronizations. If you start tweaking superset timers then you
risk triggering pollution of those synchronizations in a downstream agent.

You say that SERVFAIL applies to all answers. If you are going to say
that, you might as well say that any RCODE apply to all answers. SERVFAIL
and NXDOMAIN are equally obvious here, it seems.

Similarly, discuss CNAME processing and how it applies to multiple
questions and answers.

Is there something we can do with OPT (or a variant) such that negative
answers are clearly identified and provided with a TTL of their own?

Go ahead and discourage the use of QTYPE=ANY. No need to deprecate it,
just say "QTYPE=ANY has been proven to be only useful for testing. Here is
what you should use instead of QTYPE=ANY for non-testing lookups"

I've said this before. I think that this should be overspecified. We can
remove fluff if that is clearly unwarranted later.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Aug 2002 13:44:44 -0500

on 8/22/2002 3:27 AM Eric A. Hall wrote:

> Nowhere do you describe the behavior of caches here.

> support whatever model gets used here, too.

I think you can use section 5 from draft-hall-qtype-addr-00.txt as a start
to this.

Generally speaking, requesters MUST be prepared for queries with QDCOUNT>1
to be refused. When this happens, the requester either returns the error
to the original agent, or it issues discrete queries for the missing data
before it returns an answer. The decision should be based upon the RD and
RRD flags, and the server's willingness to perform recursion.

The discrete queries can be sent in parrallel (shotgun) so that
cumulatively this is only 2 RTTs (one for error, one for shotgun), which
is economically the same as AAAA followed by A. There is a concern here,
which is that shotgun queries should not be sent to the root servers, but
I'm not sure what is reasonable, or when reasonable can be determined (the
query might be answerable by the delegation parent so you can't just wait
until you get the authoritative NS list).

This process can be used by any requester in the chain, whether this is
the original resolver, a slave forwarding server, or a resolving server.

Note that this process will only occur once for any query, since the first
node to encounter a failure will be the last node to issue QDCOUNT>1.

Note also that the first successful query will result in the cache
learning about the authoritative servers for the zone. Any subsequent
queries which are issued will go to those servers directly, bypassing the
delegation chain.

---

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

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

> received in the query? If so, shouldn't this say that clients MUST ignore

this was fixed in the diffs sent around yesterday.

> 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

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

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

> If you can't indicate unique errors in the answers, MUST be SERVFAIL

fixed.

> >    present would yield such a response when QDCOUNT==1.

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

> I don't see a discussion on NODATA processing when it applies to ALL of

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

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

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

> Might want to include a disclaimer that this specifically does not apply

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.