resolver search order question
Kevin Darcy
kcd at daimlerchrysler.com
Fri May 26 02:09:30 UTC 2006
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
More information about the bind-users
mailing list