What is the plans for NetBSD resolver (lib/libc/net)?  Will we
	switch to BIND9 sometime in the future? (I believed so)


	I would like to address problem in PR 9039, and recent thread started
	by Frank in tech-net titled "getaddrinfo search order".

	This is about search order in getaddrinfo.  Current getaddrinfo code
	calls the following functions:
		gethostbyname2("foo", AF_INET6)
		gethostbyname2("foo", AF_INET)
	and end up looking up in following order if the search order is
	"hosts then DNS":
		IPv6 address in hosts = _gethtbyname("foo", AF_INET6)
		IPv6 address in DNS = _dns__gethtbyname("foo", AF_INET6)
		IPv4 address in hosts = _gethtbyname("foo", AF_INET)
		IPv4 address in DNS = _dns__gethtbyname("foo", AF_INET)

	The right thing to happen is to make functions like _gethtbyname() and
	_yp_gethtbyname() address family independent, and make a series
	of calls like:
		_gethtbyname2("foo", PF_UNSPEC)
		_dns_gethtbyname("foo", PF_UNSPEC)
	They would return IPv4, or IPv6, or both entries if exists.

	This needs rather major rewrite in resolver code.   Like:
	(1) make all the lower layer functions to manipulate struct sockaddr,
	    (or struct addrinfo), not in{,6}_addr.  Note that IPv4 mapped
	    address form is not prefererred for IPv6 scoped address support.
	(2) they need to support PF_UNSPEC queries.
	(3) consequently, change nsdispatch() and friends.


	Note that BIND8/9beta resolver does not address issue either.
	BIND9beta getaddrinfo seems to call following functions (or equivalent
	thing) if called with PF_UNSPEC:
		getipnodebyname("foo", PF_INET6)
		getipnodebyname("foo", PF_INET)
	and will end up same search order as above (wrong one).
	Of course, I'll be very happy to contribute changes for BIND9 to ISC.

	What should we do to address this?
	1. leave it as is for BIND4-based resolver, try to fix it in BIND9,
	   and switch to BIND9 whenever it is made available.
	2. fix it in BIND4-based resolver by ourselves (this would make
	   it harder to switch to BIND9).  separately make effort to fix
	   BIND9.
	3. other routes?

itojun