Summary time, I guess.  The short of it is that when I first raised
this question, the KAME integration affected the behaviour of the
resolver in non-IPv6 networks.  itojun has committed a workaround
in getaddrinfo() which means that existing non-IPv6 systems will
no longer be affected by the problem, they are returned to
status quo ante.  To that extent, my immediate concerns are allayed,
and I thank him.  [ I have updated my libc.so and my symptoms have
gone away.  So it works.  Thanks, itojun ! ]

The underlying problem remains, and but I will leave it to others
to pursue.  Since this is a wider issue than just for NetBSD, I do
not believe I need to file a NetBSD PR to preserve its history,
correct me if I'm wrong.

[ if you're not interested in my response to Andy, skip to next msg now ]

To answer Andy Doran <ad@fionn.sports.gov.uk> who wrote:

} How about an extra option for 'options' in /etc/resolv.conf that 
} knocks the TLD lookup on the head?
} 
} Useful for dial-on-demand systems (as yours is).

Well, strictly speaking, it won't help at all, as most of my
lookups succeed on the TLD lookup!  (e.g. for fionn.sports.gov.uk :-)
One could do it just for hosts without dots, but that seems
too much like a kludge to me.

Furthermore, it doesn't actually solve the underlying problem.  One
can postulate relatively simple circumstances under which the
problem would still manifest itself, even with Andy's proposed option.

Here's the postulated example:

	host a.cs.foo.edu has dns search path

	    cs.foo.edu math.foo.edu foo.edu

	dns in foo.edu includes these records:

	    bar.cs.foo.edu			A
	    bar.math.foo.edu			AAAA

	If a.cs.foo.edu were running IPv6, the actual search order
	would be

	    bar.cs.foo.edu			AAAA
	    bar.math.foo.edu			AAAA
	    bar.foo.edu				AAAA
	    bar.cs.foo.edu			A
	    bar.math.foo.edu			A
	    bar.foo.edu				A

	which would succeed on on the second lookup and get you
	connected to bar.math rather than the expected bar.cs.
	*> with or without Andy's suggested option :-) <*

	Oops.  At that point you take math.foo.edu out of your
	dns search path ;-)

Relying on search paths in the presence of ambiguous hostnames can
be risky, which is why I suspect the issue isn't actually as
important as all that.

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.

--