Re: Issue: Add a new QTYPE

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Tue, 25 Nov 2003 22:59:19 -0500
    From:        Kevin Darcy <kcd@daimlerchrysler.com>
    Message-ID:  <3FC42517.4090404@daimlerchrysler.com>

  | The standard describes the basic resolver algorithm as a) answer from 
  | your cache if you can, or b) if recursion was requested and you're 
  | willing to provide it, go get the answer from an authoritative server or 
  | upstream resolver. Now, it's hard for me to read into that that a known 
  | *incomplete* answer from cache is acceptable to pass back to the client 
  | even though a complete answer is available via recursion.

What is a "known incomplete answer"?   How can the cache possibly know
whether what is cached is complete or not?   The effect of enforcing the
protocol that you're suggesting should be enforced, is that any QTYPE=* RD=1
query must be sent to an auth server, and the reply forwarded back to the
client - a cache could cache the results, but not for use in any later
QTYPE=* query, only specific queries.

Since caches are a primary object in the DNS, and everything is designed
around making caches effective, it is almost impossible to conceive that
a query that explicitly avoids the cache could possibly have been intended.

If the client wants to defeat caching, let the client talk directly to an
auth server for the name (and do the extra work to find that server).
Explicitly requiring caches to defeat their reason for existing would be
absurd.

  | As was 
  | clarified later, dropping individual RRs from an answer RRset is illegal 
  | (except for properly-flagged truncation scenarios), why should it be any 
  | more legal to drop whole RRsets from a QTYPE=* response for any reason 
  | other than properly-flagged truncation or the fact that the only way to 
  | provide the missing RRset(s) would be to recurse, and recursion was 
  | either not requested or not available?

They're not being dropped, they simply aren't available at the server
queried to ask.   I'm actually somewhat skeptical of having a cache to
a QTYPE=* request of the auth server if it has no data about the name,
I think I'd prefer to have it simply return NODATA in that case (or
NXDOMAIN if it knows the name doesn't exist) - the only real problem
with that would be the possibility of getting a NODATA for a name which
really doesn't exist (or perhaps a NXDOMAIN for a name that does if
that was the selected response to an ANY query for a name not in the cache).

  | That is arguably what it has become. I still don't agree that that is 
  | what was originally intended or specified.

Nothing says why it was originally specified, in fact, it isn't clear
that there was any reason at all, other than "this looks nice and easy"
(which turned out to be wrong on both counts - if t hat was the explanation).


I support leaving QTYPE=* defined as it has been implemented everywhere.
Return any data in the server receiving the query (ignoring RD if there
is any such data) - if there is none, then send a non-auth NODATA (or a
referral, I guess, that would be better) (again regardless of RD).
Implementations that choose to honour RD when there is no data are OK,
as from the outside no-one can tell if the data existed before the
query or only after it was received - so returning the answer from a
query is OK (as I guess is an implementation which actually always does
a query of the auth server when RD=1 - though I'd never deploy such
a thing).

kre


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