Odd search order and delegation problem

Adam Augustine adam_augustine at morinda.com
Wed Dec 20 23:21:57 UTC 2000


Ah. This is very useful for our clients that use a resolv.conf file. We will
experiment with this to see if we can find a happy medium.

Thank you very much,
	Adam Augustine

-----Original Message-----
From: Waltner, Steve [mailto:swaltner at lsil.com]
Sent: Wednesday, December 20, 2000 4:04 PM
To: bind-users at isc.org
Subject: RE: Odd search order and delegation problem


The problem is with your clients, not the server. You are searching for a
host called multi.de, which exists in Internet land

ra:~> nslookup multi.de
Server:  jupiter.ks.lsil.com
Address:  153.79.160.71

Name:    multi.de
Address:  194.9.194.37
The other host multi.au is not a valid FQDN hostname, therefore when your
DNS client searches for a host called multi.au. it doesn't find it, then the
client tries again with search domain appended to multi.au which resolves
with your local server. If you had a host on your system called
www.isc.org.example.com, you would run into a similar problem if you tried
to load http://www.isc.org/ in a web browser and your search config was set
to example.com.

One possible solution is the ndots option in the resolv.conf file. This is
from Solaris' resolv.conf(4) man page...

                         ndots:n   Sets a floor threshold for the
                                   number   of  dots  which  must
                                   appear  in  a  name  given  to
                                   res_query() (see resolver(3N))
                                   before  an  initial   absolute
                                   (as-is)  query  is  performed.
                                   The default for n is 1.  Thus,
                                   if  there  are  any  dots in a
                                   name, the name is tried  first
                                   as an absolute name before any
                                   search-list domain  names  are
                                   appended to it.
Try adding "options ndots:2" to your /etc/resolv.conf file on the client.
That should make the client try a query for multi.de.example.com when you
enter the hostname as multi.de. The drawback is that you'll likely loose
access to web sites with a URL like http://isc.org/ since your system would
then be trying to find a host called isc.org.example.com. You might be able
to get around that by adding '.' to the search domain list. So you might
need to use the following as your resolv.conf file:

search example.com .
nameserver 127.0.0.1
nameserver 10.1.6.3
options ndots:2

--
Steve Waltner
LSI Logic
Steve.Waltner at lsil.com

> ----------
> From: 	Chicken Man
> Sent: 	Wednesday, December 20, 2000 3:07 PM
> To: 	bind-users at isc.org
> Subject: 	Odd search order and delegation problem
> 
> 
> We seem to have a strange problem with the order that the resolver
> searches 
> domains. We are using 8.2.2P7 on all our nameservers, which are running on
> 
> either Red Hat or Caldera Linux. All clients (regardless of OS) experience
> 
> this problem.
> 
> We have, on our internal network (not visible to the Internet),
> delegations 
> from our corporate office to our remote country offices that follow this 
> form:
> 
> de.example.com
> au.example.com
> ca.example.com
> 
> and so on. And the resolv.conf at the corporate office name server looks 
> like this:
> 
> search example.com
> nameserver 127.0.0.1
> nameserver 10.1.6.3
> 
> Here is an illustration of the problem:
> 
> [root at kando named]# ping multi.au
> PING multi.au.example.com (10.11.6.1) from 10.1.6.1 : 56(84) bytes of
> data.
> 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=0 ttl=253 
> time=378.4 ms
> 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=1 ttl=253 
> time=379.4 ms
> 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=2 ttl=253 
> time=379.7 ms
> 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=3 ttl=253 
> time=385.9 ms
> ò
> --- multi.au.example.com ping statistics ---
> 4 packets transmitted, 4 packets received, 0% packet loss
> round-trip min/avg/max = 378.4/380.8/385.9 ms
> [root at kando named]# ping multi.de.example.com
> PING multi.de.example.com (10.21.6.1) from 10.1.6.1 : 56(84) bytes of
> data.
> 64 bytes from multi.de.example.com (10.21.6.1): icmp_seq=0 ttl=251 
> time=213.5 ms
> 64 bytes from multi.de.example.com (10.21.6.1): icmp_seq=2 ttl=251 
> time=200.8 ms
> 64 bytes from multi.de.example.com (10.21.6.1): icmp_seq=3 ttl=251 
> time=218.7 ms
> ò
> --- multi.de.example.com ping statistics ---
> 4 packets transmitted, 3 packets received, 25% packet loss
> round-trip min/avg/max = 200.8/211.0/218.7 ms
> [root at kando named]#
> 
> Both of which behave as expected given the resolv.conf. But...
> 
> [root at kando named]# ping multi.de
> PING multi.de (194.195.64.35) from 10.1.6.1 : 56(84) bytes of data.
> From router.example.com (10.1.1.1): Destination Host Unreachable
> From router.example.com (10.1.1.1): Destination Host Unreachable
> From router.example.com (10.1.1.1): Destination Host Unreachable
> From router.example.com (10.1.1.1): Destination Host Unreachable
> ò
> --- mail.de ping statistics ---
> 4 packets transmitted, 0 packets received, +4 errors, 100% packet loss
> [root at kando named]#
> 
> Which is the Internet multi.de address rather than multi.de.example.com,
> not 
> what one would expect with the resolv.conf as shown above.
> 
> The entries in the named.conf file look like this:
> 
> /* The Australia network */
> zone "au.example.com" {
>         type stub;
>         file "stub/au/au.example.com";
>         masters {
>                 10.11.6.1;
>         };
> };
> 
> zone "de.example.com" {
>         type stub;
>         file "stub/de/de.example.com.zone";
>         masters {
>                 10.21.6.1;
>         };
> };
> 
> It does retrieve the glue and place it in the file.
> 
> There are no entries in the example.com zone file for anything in the 
> de.example.com domain. Here is the zone file on 10.21.6.1:
> 
> $TTL 86400
> @       IN      SOA     multi.de.example.com. hostmaster.example.com (
>                 2000082100      ; Serial YYYYMMDDxx format where xx=0-99
>                 10800           ; Refresh in seconds
>                 3600            ; Retry in seconds
>                 3600000         ; Expire in seconds
>                 86400   )       ; Negative cache time
> 
> ;Nameservers
>                 IN      NS      multi.de.example.com.
> 
> ;Mail Relays
>                 IN      MX      20      multi.de.example.com.
> 
> ;Routers
> router          IN      A       10.21.1.1
> 
> ;Servers
> multi           IN      A       10.21.6.1
> mail            IN      CNAME   multi.de.example.com.
> 
> I really can't find any difference between the two delegations, and any 
> ideas anyone might have would be appreciated.
> 
> Thanks
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 
> 
> 
> 




More information about the bind-users mailing list