ANY queries and Recursion

Kevin Darcy kcd at daimlerchrysler.com
Tue Aug 15 21:48:04 UTC 2000


Eric A. Hall wrote:

> [Kevin Darcy:]
>
> > > The nameserver, after all, is not obligated to seek out the best
> > > _possible_ answer to a QTYPE=* query, even if it's providing
> > > recursive service.
>
> Somebody has to do it, it might as well be the servers which are fetching
> the data in the first place. Why force it onto the clients? What possible
> value is there in that?

The value is that not many clients, if any, really need *full* answers to
QTYPE=* queries, and it's a burden on the server to provide them.

> In addition, when the query is for qtype=ALL then by definition you want
> ALL records, not ANY records which match.

That's just semantics. Note that I've studiously avoided using the term
"QTYPE=ANY" or "QTYPE=ALL" in this thread, for just this reason, because the
tokens "ALL" or "ANY" are meaningless to the nameserver; all it sees is a
QTYPE value of 255, commonly represented textually by "*".

> Just as the qclass=ANY construct
> requires special handling, so should qtype=ALL, and for pretty much the
> same reasons.

The RFCs don't require exhaustive searches for QCLASS=* either.

Eric, I'm not sure whether your main point is: a) BIND violates the RFC or
b) there *should* be a way to get a full answer to a QTYPE=* query. From the
RFC examples, it appears quite legal to return a partial answer to a
QTYPE=* query, and this is also supported by common usage. If (b), then maybe
a new QTYPE, or an EDNS option, could be proposed, but I think it should be
*optional* for the server to honor such a request, so as not to put the
performance/capacity of nameservers everywhere at the mercy of lazy
application programmers.


- Kevin







More information about the bind-users mailing list