Different handling of referrals by dig and nslookup

Kevin Darcy kcd at chrysler.com
Mon Feb 22 15:09:59 UTC 2010


On 2/21/2010 8:25 PM, Doug Barton wrote:
> On 02/20/10 08:54, kalpesh varyani wrote:
>    
>> Thanks Dave for pointing this out.
>>
>> the first server did not fail, it behaved as per its configuration.
>> But for a stub resolver, which cannot follow referrals, isnt it logical
>> for it to detect referrals and move on to the next name server in the list?
>>      
> No. What you're describing is the function of a resolving name server,
> not a stub resolver. If you think that the stub resolver should behave
> differently you need to take that up with your OS vendor.
>
>    
Stub resolvers are described briefly in RFC 1034, Section 5.3.1. The 
verbiage in that paragraph "The user also needs to verify that the 
listed servers will perform the
recursive service" clearly assumes that all of the resolvers used by the 
stub support recursion. The behavior of a stub resolver when receiving a 
referral (non-recursive) response is *undefined* by the standards, and 
something to be avoided.

As Doug pointed out, if the resolver is sophisticated enough to deal 
with non-recursive queries, then that goes beyond what is expected of a 
"stub" resolver, described in the RFC as typically "a PC which lacks the 
resources to perform the resolver
function".

                                                                         
                                                                         
- Kevin





More information about the bind-users mailing list