Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!sdd.hp.com!spool.mu.edu!uunet!pipex!demon!demon.co.uk!ronald Newsgroups: comp.unix.bsd From: ronald@demon.co.uk (ronald) Cc: terry@icarus.weber.edu Subject: Re: 386BSD gethostname() problems References: <1992Oct8.044051.19526@fcom.cc.utah.edu> Organization: Demon Systems Ltd. Date: Sun, 11 Oct 1992 01:07:09 +0000 Message-ID: <9210110207.aa25830@demon.demon.co.uk> Sender: usenet@gate.demon.co.uk Lines: 28 In article <1992Oct8.044051.19526@fcom.cc.utah.edu> you write: > 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. Please don't make /etc/hosts-first the default in your patch kit. It's true that the default search order is inconvenient, but in a large networked situation, it's usually the best default. /etc/hosts really should be treated in a similar sort of way to root.cache (not the same, but sort of similar) as a last resort source of resolution information. The rule is normally to trust the DNS more than any statically coded data because the DNS likely to be right, given that other people use the DNS, but only you yourself use /etc/hosts. It's true that a more configurable resolver would be useful. One free enhanced resolver that comes to mind is (I think) Bill Wisner's resolv+-2.1 which archie should be able to find. However, the *default* as shipped with either the base distribution or an official patch should be as it currently is, if only not to break the expectations of the experienced BIND administrators. In any case, I would humbly suggest taking advice from the wizards in comp.protocols.tcp-ip.domains before taking any action. This issue if important enough to warrant its own newsgroup, is definitely important enough to warrant considering carefully.