grins@mips.COM (Randall Grinstead) (10/25/90)
A friend of mine has been having some problems configuring a name
server. The primary master server is on a Sun and serves a LAN.
This LAN (LAN #1) is bridged to another LAN (LAN #2) so that both
LAN's appear as to be the same.
The hosts on LAN #1 however are in a different zone than those on
LAN #2. Everything was running perfectly until the repeater to
LAN #1 went out, isolating LAN #1. What he found was that when
using nslookup, when hosts were addressed by their non-expanded
name or alias, the address resolution would occur as expected.
When a fully qualified name was used, the search would fail. Ex-
ample:
"abc" would obtain the address for abc.x.ab.com ok.
"abc.x.ab.com" would fail.
What appeared to be happening was that the later request would
somehow filter up to LAN #1 , and then somehow get resolved. The
question is why? It seems that this is not a normal type of
behaviour, and that all requests within a zone should be resolved
without going outside of the zone.
Any help would be appreciated. Thanks in advance!
--
Randy Grinstead I speak only for myself, etc., etc., etc.
UUCP: {ames,decwrl,prls,pyramid}!mips!grins
INTERNET: grins@mips.COM (grins%mips.com@ames.arc.nasa.gov)
USPS: MIPS Computer Systems, 950 DeGuigne, Sunnyvale, CA 94086cricket@WINNIE.CORP.HP.COM ("Cricket") (11/07/90)
Randy,
(My apologies if you've already gotten an answer to your question.)
A friend of mine has been having some problems configuring a name
server. The primary master server is on a Sun and serves a LAN.
This LAN (LAN #1) is bridged to another LAN (LAN #2) so that both
LAN's appear as to be the same.
The hosts on LAN #1 however are in a different zone than those on
LAN #2. Everything was running perfectly until the repeater to
LAN #1 went out, isolating LAN #1. What he found was that when
using nslookup, when hosts were addressed by their non-expanded
name or alias, the address resolution would occur as expected.
When a fully qualified name was used, the search would fail. Ex-
ample:
"abc" would obtain the address for abc.x.ab.com ok.
"abc.x.ab.com" would fail.
What appeared to be happening was that the later request would
somehow filter up to LAN #1 , and then somehow get resolved. The
question is why? It seems that this is not a normal type of
behaviour, and that all requests within a zone should be resolved
without going outside of the zone.
I think your friend's problem has to do with the search list. A
search list (pardon me if you know this already) is a list of domains
appended to non-dot-qualified domain names in an attempt to figure
out what the real domain name is. In your friend's case, the search
list is
x.ab.com
ab.com
(nothing)
For example, if he types "telnet foo", the following domain names are
looked up by the resolver:
foo.x.ab.com
foo.ab.com
foo
When the repeater failure segmented his network, the x.ab.com
nameserver was isolated from the ab.com nameserver. Now when your
friend tried to "telnet foo", the first query that the resolver sent
out was for foo.x.ab.com, which was answered by the local nameserver,
authoritative for x.ab.com. But if your friend tried to "telnet
foo.x.ab.com", the resolver first looked up foo.x.ab.com.x.ab.com,
which the local nameserver could immediately tell was bogus, and then
foo.ab.com.
foo.ab.com, I think, was the problem. Only an ab.com nameserver
could answer authoritatively, and none were available because of the
network failure. If the x.ab.com nameserver was unlucky enough not
to have cached the NS records for ab.com (unlikely, as ab.com is its
parent domain), it may have tried unsucessfully to get to the root
nameservers to find out what the ab.com nameservers were.
Either way, the resolution probably stopped there. I'm not sure of
the internals, but I'd bet that gethostbyname() probably times out
and doesn't go on to try the next element of the search list.
In a situation like this, your friend could have advised his users to
use either simple, one-part names (the ones that worked), or to dot-
qualify the domain names to override the search list facility. So,
for example, they'd "telnet foo.x.ab.com."
cricket
hostmaster@hp.com