>  *  "Erik E. Fair" <fair@clock.org> wrote:
>  * 
>  *  > NetBSD's default should reflect common usage. The common usage is "DNS,
>  *  > files" in that order. This should work when there isn't an nsswitch.conf.
It depends upon your definition of "common usage".  My preferred definition
would be "what the reference implementation does", which, according to
http://www.isc.org/bog-4.9.4/bog-sh-7.html#sh-7.3 (latest HTML version
available at the reference site :-) is:

        If DNS available, use DNS only, else use files

I don't see how to configure a nsswitch.conf to give me this 
behaviour which is arguably the correct one.  (I haven't
upgraded yet, but I assume that an NXDOMAIN response
to a "dns, files" configuration would still result in
a bogus value in /etc/hosts being returned ?)

>  * It is?  I have always been of the belief that "files dns" was a more
>  * appropriate order... saves annoying timeouts in some situations.

If your system as a whole (resolver, dns servers, network etc)
is correctly configured, you should not get annoying
timeouts.  Much worse is the very real likelihood that data in
/etc/hosts that was once crucial and correct is now neither, and leads
to strange behaviour.  One assumes that if the machine is up, then the
/etc/hosts data that was used to get it up is correct :-) but anything
else in there is suspect.

The argument that "going to network" is slower than "local" resolution
is also mostly false.  It's actually quicker in the typical case (by an
irrelevant amount)  because the filesystem lookup will normally fail
and is done in addition the the typically required DNS lookup.

I agree that DNS spoofing can be a legitimate reason to want to
use "files, bind" but I'd argue that that is an unusual "special
case" application.  The typical user is more likely to be
bitten by incompetence (invalid /etc/hosts) than malice.

I'm not saying that DNS spoofing should be ignored, I'm just saying
that you should secure against it in the boxes run by the clueful since
the clueless aren't going to get it right anyway.  Typical clueless
person should be told to slave his local nameserver to a properly
secured one behind the firewall/ run by a competent ISP/whatever, and
solve the problem >there<.

I'm here speaking as an incompetent user who *did* use "files, bind"
for a network, (which I was too lazy to sort out the long timeouts
for :-) and *did* get badly bitten by bad /etc/hosts data
then >finally< believing the original BIND documentation which
for many years has warned us to trust in the DNS as the one
and only source of authoritative data :-)

[ Flame suit now on, but where traditional behaviour is (gasp!)
  still correct and applicable, it should have its defenders :-) ]

--