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

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

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

on 8/14/2002 8:21 PM Paul Vixie wrote:

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

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

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

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

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?

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

>    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

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

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

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/

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