mb@rex.cs.tulane.edu (Mark Benard) (09/30/89)
We have several Suns which are running OS 4.0.3 and which are nameserver clients to another system (which is not a Sun) we have. Recently we noticed that when those Suns make a nameserver query (generated by mail, rlogin, or nslookup), they append the local domain name "cs.tulane.edu", even if the name being queried 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. Meanwhile their only suggestion was to put a null domain name in /etc/resolv.conf and use only fully qualified domain names. If I do this, mail seems to work out ok, but in order to rlogin to "host" from a Sun, "host" has to be a fully qualified domain name or must be in the YP database. But to put all hosts on campus in every YP database is impossible; that's why we have a nameserver. And it is even more impossible to convince users that they must always use fully qualified domain names for campus hosts. Does anyone know of another solution that I can use? On a similar topic, I noticed that MX-ing did not seem to work on these Suns. I asked a local Sun software support person and he said that he was not sure, but he thought that MX-ing was not supported in Sun OS 4.0.3 sendmail and that there might be a fix for it in a named fix kit available on uunet.uu.net. Can anyone give me a definitive answer on that? Thanks, Mark Mark Benard Department of Computer Science INTERNET & BITNET: mb@cs.tulane.edu Tulane University USENET: rex!mb New Orleans, LA 70118
parmelee@wayback.cs.cornell.edu (Larry Parmelee) (10/06/89)
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