'dig -t any ...' question
Kevin Darcy
kcd at daimlerchrysler.com
Thu Jun 17 01:25:45 UTC 2004
Barry Margolin wrote:
>In article <caobi7$1lkv$1 at sf1.isc.org>,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>
>
>>Nowhere is there a specific example in RFC 1034 of a response to a
>>*recursive* QTYPE=* query, but one would assume, based on generic
>>descriptions of recursive resolvers and how they are supposed to
>>operate, that a recursive resolver would make its best efforts to get a
>>complete answer, which clearly BIND and other implementations do not.
>>
>>
>
>The server algorithm says that when a query has RD set, the server
>should consult its resolver. If you read the section on the resolver
>algorithm, it says that if the records are already in the cache it
>doesn't need to query the authoritative server.
>
Actually, what RFC 1034 says in the resolver algorithm description is
"See if the *answer* is in local information" (emphasis mine). Not just
any old records that happen to be owned by the QNAME, but the *answer*
to the query. I suppose reasonable people could disagree over exactly
what "answer" means in that context, but it seems a rather strange
interpretation to me to say that a recursive resolver can choose to give
the client *less* of an answer than it wanted (note that the description
of the "General Lookup Function" in Section 5.2.1 refers to the client
wanting "*all* of the matching RRs" (emphasis added)), even when a
complete answer is available via recursion, recursion was requested by
the client and the availability of recursion is being advertised by the
recursive resolver via the RA bit. If the client wanted a least-efforts
answer, it wouldn't have set RD=1 in the first place, surely. The
description of the RA flag in the RFCs is not "Recursion Available,
except for QTYPE=* queries, to which I'll give partial answers from
cache if I don't feel like recursing for something better"...
- Kevin
More information about the bind-users
mailing list