resolver search order question

[Norman P. B. Joseph]

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

[Kevin Darcy]

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

Post by Norman P. B. Joseph
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.
search ctc.com ctcgsc.org ad.ctcgsc.org
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

[Norman P. B. Joseph]

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

Post by Kevin Darcy
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

Post by Norman P. B. Joseph
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.
search ctc.com ctcgsc.org ad.ctcgsc.org
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

[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

Post by Norman P. B. Joseph
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

Post by Kevin Darcy
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

Post by Norman P. B. Joseph
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.
search ctc.com ctcgsc.org ad.ctcgsc.org
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

[Norman P. B. Joseph]

Well, here's the output from "dig":

------
% dig +search aj-mail1

; <<>> DiG 9.2.4 <<>> +search aj-mail1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13973
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;aj-mail1.ctc.com. IN A

;; AUTHORITY SECTION:
ctc.com. 900 IN SOA server3a.ctc.com. postmaster.ctc.com. 2006052503 10800 1800 2419200 900

;; Query time: 396 msec
;; SERVER: 10.160.17.10#53(10.160.17.10)
;; WHEN: Fri May 26 08:14:58 2006
;; MSG SIZE rcvd: 90
------

Status says NOERROR. Is there some other tool or switch or
debugging/logging option I can use to see more clearly what is occurring
here?

Thanks,

-norm

Post by 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 Darcy]

Well, I guess at this point one option would be to go back to nslookup
and run it with -debug. The way that it uses the "search" directive
should be a fairly close approximation to what your system resolver is
doing. See if it's appending the suffixes you expect, and what responses
it is getting to those queries.

Alternatively, look at the query logs on the server to see what is being
queried, and then "dig" those queries to see what the responses are.


- Kevin

Post by Gregory Hicks
------
% dig +search aj-mail1
; <<>> DiG 9.2.4 <<>> +search aj-mail1
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13973
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;aj-mail1.ctc.com. IN A
ctc.com. 900 IN SOA server3a.ctc.com. postmaster.ctc.com. 2006052503 10800 1800 2419200 900
;; Query time: 396 msec
;; SERVER: 10.160.17.10#53(10.160.17.10)
;; WHEN: Fri May 26 08:14:58 2006
;; MSG SIZE rcvd: 90
------
Status says NOERROR. Is there some other tool or switch or
debugging/logging option I can use to see more clearly what is occurring
here?
Thanks,
-norm

Post by 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...

[Norman P. B. Joseph]

(Note: *I THINK* ... I may be wrong but this is what experience has
taught.) I think that this may depend on the ORDER that the "domain"
and "search" directives are presented in /etc/resolv.conf. Whichever
one is last is the one that has precedence.

That's the behavior that's described in the DNS & BIND book (4th ed. p.
106), so you're right there. But it also says that "search" and
"domain" directives are mutually exclusive, so I've used only the
"search" directive here, no "domain" directive", in order to get the
behavior of searching for unqualified names under multiple domains. Or
so I thought. I seem to have stumbled across a situation where it
appears it doesn't want to search multiple domains and I'm trying to
understand why.

-norm

[Gregory Hicks]

Subject: Re: resolver search order question
Date: Thu, 25 May 2006 16:47:26 -0400
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?

(Note: *I THINK* ... I may be wrong but this is what experience has
taught.) I think that this may depend on the ORDER that the "domain"
and "search" directives are presented in /etc/resolv.conf. Whichever
one is last is the one that has precedence.

domain example.com
search example1.com subdomain.example.com

will use example1.com and subdomain.example.com as the names to tack on
non-FQDN names. example.com is ignored. (Use FQDN!)

while:

search example1.com subdomain.example.com
domain example.com

Only uses example.com for the non-FQDN names... example1.com and
subdomain.example.com are ignored. (Again, use FQDN!)

Regards,
Gregory Hicks

Sorry if my original post wasn't clear.
-norm

Post by Kevin Darcy
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

Post by Norman P. B. Joseph
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.
search ctc.com ctcgsc.org ad.ctcgsc.org
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

--
Concurrent Technologies Corporation 814/269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
--=: It's not the voting that's democracy, it's the counting. :=--

-------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
Cadence Design Systems | Direct: 408.576.3609
555 River Oaks Pkwy M/S 6B1 | Fax: [phone]
San Jose, CA 95134 | Internet: ***@cadence.com

I am perfectly capable of learning from my mistakes. I will surely
learn a great deal today.

"A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton