resolver search order question

[Kevin Darcy]

Yes, you are correct, I misinterpreted your question.

I just performed a little test here, and it seems that a NODATA response 
causes a failover to the next element in the searchlist, just as an 
NXDOMAIN would. I don't know why it wouldn't do that in your setup. Have 
you confirmed that the response is actually NODATA? I could maybe 
understand if it were SERVFAIL, NOTIMP, FORMERR or something like that, 
the resolution algorithm might stop dead in its tracks...

                                                                         
                                             - Kevin

Norman P. B. Joseph wrote:

>But I wasn't asking about multiple "nameserver" directives in
>resolv.conf, I was asking about multiple domains in a "search"
>directive.
>
>You're saying getting a NODATA response for "aj-mail1.ctc.com" (tagging
>on the first domain in the search directive) would cause the resolver to
>return that as a definitive answer and to not consult other nameservers.
>I understand that, but that wasn't my question.  My question was, "Why
>doesn't the resolver tag on the next domain name in the search directive
>and search again until found or no more domains are left to search?"
>Isn't that what the "search" directive is for?
>
>Sorry if my original post wasn't clear.
>
>-norm
>
>
>
>On Thu, 2006-05-25 at 16:29 -0400, Kevin Darcy wrote:
>  
>
>>Right, the purpose of having multiple resolvers in the resolver list is 
>>to enhance availability, not to accommodate disparate namespaces or get 
>>a "second opinion" on lookups. All resolvers in the resolver list are 
>>assumed to have the same data, temporary replication delays 
>>notwithstanding. So, as soon as an answer is received from one resolver, 
>>even if it's a SERVFAIL, NXDOMAIN, NODATA (a pseudo-RCODE meaning 
>>NOERROR and an empty Answer Section, as you'd be getting here for 
>>aj-mail1.ctc.com), it's treated as definitive and the other resolvers 
>>are not consulted.
>>
>>                                                                         
>>                                       - Kevin
>>
>>Norman P. B. Joseph wrote:
>>
>>    
>>
>>>Is this expected resolver behavior?  It doesn't fit my understanding,
>>>but maybe my understanding is at fault.  The clients and servers in this
>>>scenario are all BIND 9.2.4 under RHEL.
>>>
>>>I have the following search order in a client's resolver configuration:
>>>
>>>       search ctc.com ctcgsc.org ad.ctcgsc.org
>>>
>>>and I have the following two RRs in our DNS space:
>>>
>>>       aj-mail1.ctc.com.	MX	0 aj-mail1.ad.ctcgsc.org.
>>>       aj-mail1.ad.ctcgsc.org.	A	10.x.x.x
>>>
>>>If I look for an A record for an unqualified "aj-mail1" the query fails,
>>>but if I fully qualify the name in the query it succeeds.  I would have
>>>expected the resolver to append the domains in the "search" directive in
>>>order to the query name until it found "aj-mail1.ad.ctcgsc.org".
>>>
>>>I'm guessing that the resolver discovers the label "aj-mail1.ctc.com"
>>>first, because of the order of domains in the "search" directive, but
>>>since it is an MX record and not an A record the search fails, but the
>>>resolver doesn't continue with the other search domains because of the
>>>existence of the label.  Or something like that.
>>>
>>>What's the correct behavior?
>>>
>>>-norm
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>