'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