[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: draft-dnsext-edns1-04.txt
From:       Paul Vixie <paul () vix ! com>
Date:       2002-08-23 1:28:04
[Download RAW message or body]

> >    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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
[prev in list] [next in list] [prev in thread] [next in thread]