Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!snorkelwacker.mit.edu!tamsun.tamu.edu!bcm!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: 386BSD gethostname() problems
Message-ID: <1992Oct8.044051.19526@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
Date: Thu, 8 Oct 92 04:40:51 GMT
Lines: 81
Well, it bit me, so now it's obnoxious enough to do something about
it. 8-(.
It seems that the functions "gethostbyname()" and "gethostbyaddr()"
in the file "/usr/src/lib/libc/net/gethostnamadr.c" attempt to query the
resolver *first*. They fall back to the local "/etc/hosts" file only if
they get the error "ECONNREFUSED". The problem is that this is the wrong
way to do things.
I posit:
1) Local alias names in /etc/hosts should take precedence over
resolver names, both as a means of providing preferred path's
to machines and as an administrative override.
a) A machine is on two networks. The local machine is on
the same two networks. The name server reply to the
local machine has the potential for suggesting the
address on the second net instead of the address on the
first if the name on the second net is used to connect.
A local alias for the name on the second net specifying
the first net address should be checked *before* the
resolver response. Thus an administrator can override
default route choices resulting from an intentional or
unintentional use of the second net name for the host.
b) Access to a machine is discouraged from the local host;
thus an invalid address may be specified for that machine
in the local "/etc/hosts" file prevent by-name reference.
I say "discouraged", since this is not a lockout mechanism.
2) Local names (non-aliased) should be referenced out of the local
"/etc/hosts" file to allow for subnet aliases on the main network.
a) A situation exists where the existance of local hosts
behind a firewall should not be broadcast to the world
by way of DNS/BIND. Local "/etc/hosts" entries allow
a mechanism for the existance of machines at the given
addresses to be "hidden" from outside observation. This
is obviously simply an additional step over and above
a routing firewall disallowing incoming connections.
b) Local aliases for machines in a parallel logical subnet
allow subnetting of high network traffic resources without
damaging the ability to use non or partially qualified name
in the same physical subnet but a different logical subnet
between machines on the subnets. For instance, X terminals
on a logical subnet to prevent X traffic on logical subnets
other than the X subnet. This will not reduce the amount
of inter-logical subnet traffic unless there is some
corresponding division of logical subnets on the basis of
traffic to reduce the amount of inter-sub net connections.
3) A "lookup my address by my name" during configuration has no value
without some non-standard mechanism being employed (ala Macintosh
datagram queries). This is because recognition of return packets
from the resolver requires we know our address.
Basically, this means that the "gethostbyname()" and "gethostbyaddr()"
should look in "/etc/hosts", and *then* go to the resolver if the lookup
there fails; the current order causes names in the local hosts file to
not be resolved, *even* if they are not resolved by the resolver.
If anyone can make a case for *not* resolving from "/etc/hosts" with the
resolver active, or doing the "/etc/hosts" lookup *after* the resolver
lookup, please speak up. Otherwise, I'll make a patch for it if no one
speaks up within about a week.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------