Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!rice!sun-spots-request
From: parmelee@wayback.cs.cornell.edu (Larry Parmelee)
Newsgroups: comp.sys.sun
Subject: Re: Namserver problems in Sun OS 4.0.3
Keywords: Networks
Message-ID: <1985@brazos.Rice.edu>
Date: 6 Oct 89 12:43:04 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 54
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 155, message 2 of 7

In article <1936@brazos.Rice.edu> you write:
X-Sun-Spots-Digest: Volume 8, Issue 152, message 5 of 12

[Editted for brevity: -Lcp]

> We have several Suns running OS 4.0.3 which are nameserver clients to
> another system. When those Suns make a nameserver query they append the
> local domain name "cs.tulane.edu", even if the name is fully qualified,
> such as uunet.uu.net.  It all works out in the end, since when the
> query on "uunet.uu.net.cs.tulane.edu" fails, the Suns try
> "uunet.uu.net.tulane.edu", and finally "uunet.uu.net".  But this
> generates a lot of extra nameserver queries which are a nuisance.
> 
> I asked Sun technical support about this and was told, yes, this is a
> bug that will be reported.

The behaviour you describe is a feature, not a bug.  (Sun's response
doesn't surprize me, though).  It is this behaviour which allows you to
type "rex" and have the nameserver (I should say "resolver" here) figure
out that you mean "rex.cs.tulane.edu".  Similiarly, this behaviour allows
you to type "foo.ee" when you mean "foo.ee.tulane.edu".  (If "foo.ee"
still seems like too much to type, if Sun would do away with the YP hosts
and use the nameserver resolver entirely, your users could create lists of
host aliases for themselves, so that "foo" could mean whatever they wish).

True, you get extra queries this way, but the cost of those queries (if
you have setup your local nameservers reasonably) is minimal, compared to
the advantages of being able to use "nicknames".  You should have on your
local subnet at least one machine that runs the nameserver ("named"), and
"resolv.conf" on the other machines should point to this machine.  Of
course, it's a good idea to list several machines in your "resolv.conf" if
they're available.  You should setup your designated nameserver machine so
that it has authoratative information for all hosts on your local subnet.
You can have your nameserver pick up "secondary" authority for any domain
you want, and you want to at least pick up the domain "cs.tulane.edu" (and
associated "in-addr.arpa" domains), though it would be a good idea to pick
up all of the "tulane.edu" domains as well.

Consider what happens when you then lookup "uunet.uu.net".  The resolver
will first try "uunet.uu.net.cs.tulane.edu". This involves sending a
datagram to the local nameserver machine (quick and cheap operation - if
sending a datagram weren't cheap and quick, Sun would have collapsed a
long time ago).  If the nameserver is authoratative for your local
"cs.tulane.edu" domain, it'll be able to quickly respond "No Such".  The
resolver then asks for "uunet.uu.net.tulane.edu" and gets another quick
negative response.  Finally it tries "uunet.uu.net".  If you're lucky, the
local nameserver will have this info in it's cache and you'll get another
quick response.  At worst, this is the only query of the three that
*might* require network traffic to leave your local subnet, and so is the
only query that might take appreciable time (which is why you don't want
to try that first).

-Larry Parmelee
parmelee@cs.cornell.edu