Date:        Sun, 17 Jan 1999 17:00:13 +1100
    From:        Luke Mewburn <lukem@cs.rmit.edu.au>
    Message-ID:  <199901170600.RAA10263@wombat.cs.rmit.edu.au>

  | 	I strongly feel that putting in a hack into a generic
  | 	libc routine to provide a specific default of `dns files'
  | 	for `hosts' is not the correct orthagonal thing to do.

I think this is right, but I suspect a different coding method could
avoid the problem of a missing nsswitch.conf file in a more general way,
allow different lookup types to use different defaults, and be more
resistant to future users of the file.

Now, if I read your code correctly, you're doing literally what you say
and faking up an entry with "files" in it if the config file isn't found.
That's not going to work terribly well if a new database to be accessed
sometime in the future has no "files" access method at all (kind of like
netgroup on Solaris - which I am sure glad NetBSD doesn't emulate).

Instead of building the fixed faked entry at all, an alternative would be to
simply assume that the first entry in the ns_dtab that is passed in is
the one that the particular database prefers be the default if no config
file can be found.   From that you can either build a matching ns_dbt
(rather than assuming "files") or you can simply call its callback routine
without bothering to do the matching (whichever is cleaner to code).

That one would allow the default for hosts lookup to be

	hosts: dns

(which is what I believe we ought to have, though I know for some people
that wouldn't work at all ... but then again, this is used only when the
nsswitch.conf file is missing or broken, a default of "hosts: files" breaks
things for just as many other people).

Another method would be to simply have nsdispatch() return a particular
error code to indicate "no config information available" and then let the
calling function call whatever routines it wants to call, in whatever order
it wants to call them.   With that gethostbyname() can have the same defaults
as ot now has, or any others anyone ever decides it ought havein the future.
That one will be uglier once you get dynamic linking of the back end
routines implemented, but not hugely so I don't believe.

  | 2.	*If* the dispatch code was modified to provide a default
  | 	(as Todd and others ask for), the argument then turns to
  | 	``what do you make as the default''?

There is nothing new here.   There already is a default.  Unless there's
a good reason to alter it, it should probably remain as it is.

  | 	Some people would want `dns files'.
  | 	Others (including myself) would want `files dns',

And I would prefer "dns" and no doubt there are people who would
prefer just "files".   This is not important, there needs to be
a default, but it doesn't really have to satisfy anyone too much.
Given that, easing the upgrade pain is probably the best aim (not so
much to make life easier for people who don't read the doc that comes
with the release, but to make life easier for everyone on the list who
have to read all their "why do my hostname lookups no longer work"
questions...)

  |     because
  | 	it's `safer' (such as when you depend upon lookups to
  | 	determine ifconfig/route information,

I have never understood that one.   If you believe you have to avoid a DNS
lookup for some particular usage, then I see no great advantage in adding an
indirection via /etc/hosts to get the data, you might just as well write the
number directly where it is being used rather than write it in /etc/hosts
and then refer to that entry in the place where you want the number (and run 
the risk of someone who doesn't know what they're doing changing hosts without
realising what it will affect).

  |     Michael K. Sanders also
  | 	points out that you have `files dns' to prevent DNS spoofing
  | 	of these addresses.

DNS spoofing of your own names would illustrate severe security problems.
DNS spoofing in general ought be fixed using dns security, not by avoiding
the DNS.

  | 	As far as I'm aware, the behaviour mentioned (files only
  | 	before network is available, dns only after) hasn't been
  | 	in use in NetBSD or other systems I've checked such as
  | 	Solaris and ULTRIX.

That was original BSD behaviour.   If no server was found (including when
reslov.conf didn't exist and there was no server on the local host) then
the hosts file was used.   This typically caused hosts to be used for the
lookups used by ifconfig, and absolutely nothing else (which is still too
much use of hosts for my tastes) if you were on a network, and the hosts
file to be used all the time otherwise (as you wouldn't have a DNS server
running then usually).

  | 	Alternatively, he could just put `hosts: files dns' in
  | 	/etc/nsswitch.conf, and keep /etc/hosts uptodate with those
  | 	critical hostnames you need at boot...

I need no critical hostnames at boot on systems I maintain.   Most of them
(by sheer count of numbers) get all of this info (including a suitable
resolv.conf incidentally) from Ted lemon's excellent dhclient.   On the
few that can't work that way (like the dhcp server) the IP addresses can
go directly in the ifconfig.xxN files (etc).

I know this is unusual for people used to finding all the numbers in
/etc/hosts but when you get accustomed to it for a while, you get to like
it a lot.

kre