Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1275 comp.os.386bsd.bugs:1533 comp.os.386bsd.questions:5566
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!osuunx.ucc.okstate.edu!constellation!essex.ecn.uoknor.edu!bzgoldst
From: bzgoldst@essex.ecn.uoknor.edu (Benjamin Z. Goldsteen)
Newsgroups: comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.questions
Subject: Re: I want to discuss hostname resolution (+bug report)
Date: 2 Oct 1993 20:39:05 GMT
Organization: University of Oklahoma, Engineering Computer Network
Lines: 77
Message-ID: <28kot9$os6@constellation.ecn.uoknor.edu>
References: <HERRING.93Oct1095726@loke.iesd.auc.dk>
NNTP-Posting-Host: essex.ecn.uoknor.edu
>Hi *BSDers,
>My NetBSD-0.9 machine is irritating me. It refuses to resolve
>`locahost' when the file /etc/resolv.conf exists. That is, it _never_
>looks in /etc/hosts unless res_search() sets `errno' to ECONNREFUSED
>in gethostbyname(). This problem must have been noticed by others, as
>I cannot believe that everyone has `localhost.your.domain.here' in
>their nameserver.
AIX does this too. Its great, the machine thinks its name is
"localhost.uokhsc.edu"...
>I am going to post this in the hopes that I can find out who is "in
>charge" of this portion of libc. If noone is in charge, I will "fix"
>this in libc in a pleasing and propogatable manner, and maybe even add
>a feature or two (see below).
>If this post _doesn't_ elicit any response, I'll mail to the
>maintainers listed at the end of the INSTALL_NOTES document from
>NetBSD and whoever will listen from the FreeBSD effort (the behavior
>is inherited from Net-2).
That would explain why AIX 3.2 has this misfeature -- its networking is
based on BSD4.4 networking.
>Now, to name resolution --
>The documentation is both very clear and very obscure on this point.
>The documentation in /usr/share/doc/smm/11.named says:
[ analysis of doc's and code ]
>So, short of editing the source and recompiling, there is no way to
>alter this behavior. Ergo, the docs (11.named) are wrong/vague/not
>complete or this is a bug.
>I vote for the latter.
>What _I_ want is to be able to implement resolution policy myself,
>dynamically, much as one can with sysv (ooh, no, not the
>at&t...err...novell word!!!) -- there is a file which specifies which
>services to consult for resolution information. That way, I can tell
>my machine to first ask the DNS, then look in /etc/hosts, and finally
>ask YP. Or whatever.
>Whaddaya'll think?
>Erick
Yes! I do not have NetBSD on a network machine, but when I do I
would like to be able to configure the hostname resolution like I can
under DG/UX (SVR4 + BSD?) and IRIX. Actually, the method configuration
is different in each*. At least with NetBSD one can hack the code
pretty easily -- I can not change the AIX behavior without modifying
the shared libraries.
Currently, I can not connect to our RS/6000 because our name
server is down (which it really shouldn't be, but...actually I could
wait for the timeout...).
If it takes too long to parse /etc/hosts, then perhaps we could
make the resolve routines hash it with a timestamp -- if somebody
modifies /etc/hosts, the routines would rehash it the next time a name
resolution was needed. Personally, I have never had to wait for
/etc/hosts to be parsed (granted, I wasn't using Internet before the
DNS standard came out). I have tried to keep our /etc/hosts such that
it contains every host in our subnet, but no more (although currently
it contains 146 hosts of which only 46 are in our subnet...other people
have different opinions...).
*In DG/UX, there is a file called svcorder in /etc which controls
resolution. It contains one like like: "ehosts:res" meaning first
check /etc/hosts and if not in there than check the name server.
In IRIX, the resolv.conf file is in /usr/etc and they defined an additional
keyword, "hostresorder", which one can specify to modify the default
search order which is NIS, BIND, and /etc/hosts (each of which are
authoritative if available).