ANY queries and Recursion

Kevin Darcy kcd at daimlerchrysler.com
Tue Aug 15 23:22:38 UTC 2000


Dan Nicolae wrote:

> > On top of that, caching of ANY queries, if they were required to be
> > complete answers (all rrsets), would be incredibly complicated for
> > almost no benefit.
>
> What is the benefit of an ANY query anyway?
> Assuming that some app needs it, how likely is it that the app wants ALL
> records as opposed to "one record would do it". Just wondering.

QTYPE=* has proven to be not very useful. sendmail uses it opportunistically,
but is still smart enough to make explicit A/MX queries to get the information
it needs. I don't know of any other application which regularly issues
QTYPE=* queries. The times I've analyzed my query traffic, it seems like all of
the QTYPE=* queries have been for mail targets, so I think sendmail might stand
alone in this respect.

> Secondly, the answer contains NS records in the Authority section. What's
> the point of returning those NS records (originally referrals) to the
> client?

Technically, it's not mandatory for a nameserver to return *anything* in the
Authority or Additional sections of a NOERROR response with answers. But the
server doesn't know whether the client is a stub resolver or a full-blown
forwarding nameserver. If the latter, then it's conceivable that it might find
those extra records useful. So the nameserver returns them "just in case".

But you're right: it's wasteful in most cases. I have plans to make BIND trim
unnecessary Authority and Additional sections from responses to recursive
queries. Optimize for the general case. I've been waiting for the BIND 9
codebase to settle down.

Ultimately, it would be nice if the client could let the server know whether it
wants those extra records or not (through an EDNS option or whatever). My pet
idea is that a non-caching client could even tell the server to omit TTL fields
from the response, although the packet-size savings for that would probably be
more modest than for the section-trimming.

> On one hand, it's a waste, the Answer and Authority sections are
> identical. On the other hand, the point of returning NS records in the
> Authority section is either to serve as a referral or to further qualify
> some authoritative data:
>
> RFC1034 says:
> Authority       Carries RRs which describe other authoritative servers.
>                 May optionally carry the SOA RR for the authoritative
>                 data in the answer section.
>
> What is my resolver supposed to do with the returned NS records in the
> Authority section? Use them to query directly?

A caching resolver could save those records and potentially use them to resolve
future queries.

> Well, I know it is not that simple and you have to think of old resolvers
> and compatibility issues. That's why I'm asking, RFC2308 makes an excellent
> job in enumerating possible answers and how to distinguish between NXDOMAIN,
> NODATA and REFERRAL. It would be nice to have a similar
> analysis/clarification for how to distinguish between positive answers and
> referrals, together with recommendations.

Referrals have empty Answer sections. The responses you've been talking about
had non-empty Answer sections, so they weren't technically referrals.


- Kevin





More information about the bind-users mailing list