Odd search order and delegation problem
Adam Augustine
adam_augustine at morinda.com
Wed Dec 20 23:03:20 UTC 2000
The problem is not that I can't ping. The problem is that "multi.de" is
resolving to "multi.de." rather than "multi.de.morinda.com." as I would
expect with the DNS search order specified in the resolv.conf file.
BTW, I apologize to the list for the double post and the sanitized =
version.
I had not intended to send the sanitized version after speaking with =
some
list users about how hard obfuscation and sanitization makes
troubleshooting.
sigh,
Adam Augustine
-----Original Message-----
From: Jon Bibeau [mailto:jbibeau at c-i-s.com]
Sent: Wednesday, December 20, 2000 3:38 PM
To: bind-users at isc.org
Subject: Fw: Odd search order and delegation problem
----- Original Message -----
From: Jon Bibeau <jbibeau at c-i-s.com>
To: Chicken Man <chicknmon at hotmail.com>
Sent: Wednesday, December 20, 2000 5:36 PM
Subject: Re: Odd search order and delegation problem
It looks like the system is resolving the IP addresses, but is unable =
to
ping the system in question... This doesn't look like a DNS issue. If =
you
were totally unable to resolve that would be one thing, but multi.de =
did
resolve to 194.195.64.35 but your router 10.1.1.1 doesn't know how to =
reach
the machine in question.
> ----- Original Message -----
> From: Chicken Man <chicknmon at hotmail.com>
> To: <bind-users at isc.org>
> Sent: Wednesday, December 20, 2000 4:07 PM
> 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=3D0 =
ttl=3D253
> > time=3D378.4 ms
> > 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=3D1 =
ttl=3D253
> > time=3D379.4 ms
> > 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=3D2 =
ttl=3D253
> > time=3D379.7 ms
> > 64 bytes from multi.au.example.com (10.11.6.1): icmp_seq=3D3 =
ttl=3D253
> > time=3D385.9 ms
> > =F2
> > --- multi.au.example.com ping statistics ---
> > 4 packets transmitted, 4 packets received, 0% packet loss
> > round-trip min/avg/max =3D 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=3D0 =
ttl=3D251
> > time=3D213.5 ms
> > 64 bytes from multi.de.example.com (10.21.6.1): icmp_seq=3D2 =
ttl=3D251
> > time=3D200.8 ms
> > 64 bytes from multi.de.example.com (10.21.6.1): icmp_seq=3D3 =
ttl=3D251
> > time=3D218.7 ms
> > =F2
> > --- multi.de.example.com ping statistics ---
> > 4 packets transmitted, 3 packets received, 25% packet loss
> > round-trip min/avg/max =3D 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
> > =F2
> > --- 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=3D0-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