>The real fix is for getaddrinfo to be part of the bind resolver,
>and do the path searching itself.  Or perhaps design a gethostbyname3
>which took a vector of AFs rather than the single one that
>gethostbyname2 takes, and implement getaddrinfo in terms of that
>instead.  That's not an issue for NetBSD per se.

	In discussion we had for RFC2553, gethostbyname3() did exist :-)
	for different purposes, but was replaced with getipnodebyname().
	I believe getipnodebyname() can implement the search order you
	preferred.  Current implementation of getaddrinfo(), which uses
	gethostbyname() as underlying library, is a sort of workaround.
	It should really use getipnodebyname(). However to implement
	getipnodebyname() we need a big change in resolver code.  I think
	I'd better contribute some update to bind8 tree for it and merge that
	into NetBSD, rather than doing it on NetBSD alone.

	No part of RFC2553 talks about search order in presense of search path.

itojun