Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!news.mathworks.com!fu-berlin.de!zib-berlin.de!news.tu-chemnitz.de!irz401!orion.sax.de!uriah.heep!news
From: j@uriah.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Host name
Date: 3 Jul 1996 06:26:27 GMT
Organization: Private BSD site, Dresden
Lines: 46
Message-ID: <4rd3qj$fnm@uriah.heep.sax.de>
References: <4qfhju$bi5@uwm.edu> <4qk7ki$9hc@uriah.heep.sax.de>
<4qql67$10c@anorak.coverform.lan> <4qus8k$9p@uriah.heep.sax.de>
<4r541b$167@anorak.coverform.lan>
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
NNTP-Posting-Host: localhost.heep.sax.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 0.9.6
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
brian@awfulhak.demon.co.uk (Brian Somers) wrote:
> : Apparently, sendmail, Apache etc. do call
>
> : gethostbyname("myname.my.domain.");
> : It's arguable whether this is a bug in the resolver library, but until
> : it has been fixed, adding the dot in /etc/hosts is a suitable
> : workaround. HOWEVER: you need both entries there, with and without
> : the dot!
>
> Hmmm, in that case, sendmail, Apache etc. are wrong IMO. They don't
I don't think so. I think the resolver library is wrong. An appended
dot traditionally means ``lookup this name in the root domain,
bypassing the search order''. If DNS is not in effect, the lookup via
/etc/hosts should IMHO emulate the same behaviour, i.e. it should
match a name that ends in a dot if the name is found in /etc/hosts
with all but the trailing dot.
> What's also needed is a
>
> struct hostent *gethostfortarget( struct hostent * )
Nope, this is not a resolver problem, it's a routing problem, coupled
with a design problem in these utilites that abuse DNS for finding
about a local IP address.
Look into /usr/share/examples/find_interface/ (in -current or in the
upcoming 2.1.5) for how to find about the interface address a
particular route goes out.
Look into my fixed version of talk(1) in -current or 2.1.5. The same
fix is needed for the Xserver. (Note that the problem originates in
the design of the Xserver however: it is passing what it thinks were
its own address over to the remote side. Instead, the remote side
should have used what it actually _sees_ being the remote address.
Remember, it could very easy find out about it by using
getpeername().)
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)