Thank you for your quick reply.  I guess it helps that you're in
a timezone close to mine :-)  (I'm in TZ=Asia/Kuala_Lumpur)

} 	Search path is implemented, but it is handled like:
} 		AAAA from /etc/hosts
} 		AAAA from DNS
} 		A from /etc/hosts
} 		A from DNS

Actually, I don't use /etc/hosts at all.  My problem is not with
the conflict between /etc/hosts and DNS, but with the search order
within the DNS.  At the moment it is

	broccoli.chersonese.com.	AAAA
	broccoli.			AAAA
	broccoli.chersonese.com.	A
	broccoli.			A

Searching for the second one of those entries causes my phone to dial.
I contend that the search order should be

	broccoli.chersonese.com.	AAAA
	broccoli.chersonese.com.	A
	broccoli.			AAAA
	broccoli.			A

so that resolv.conf's search path takes precedence over address
family.  But of course, RFC 2553 is silent on the issue.
(BTW there's a typo in getaddrinfo(3) that refers to it as RFC 2533 :-)

} 	The latter one is hard to implement at this moment
} 	(getaddrinfo using gethostbyname2 inside), but once we implement
} 	getipnodebyname in libc, we may be able to do the latter.

I think this is also true for my search path issue.  It's a case
where there is code variously from ISC, KAME and NetBSD with more
than one inheritance path.  I guess you being a developer of
two out of three of the above have an advantage :-)

[ irrelevant stuff ]

}       It looks that the right thing to do is to put unauthorized secondary
}       nameserver for chersonese.com in your home,

No, I have a *different* DNS zone at home, which contains data for
hosts in chersonese.com which are on the Internet, as well as hosts
which are on my rfc1918 network at home.  The public DNS only
has data for the former.  RFC 1918 section 3:

    Indirect references to such addresses should be contained within the
    enterprise. Prominent examples of such references are DNS Resource
    Records and other information referring to internal private
    addresses. In particular, Internet service providers should take
    measures to prevent such leakage.

Of course with IPv6 all this kind of rubbish should disappear, but
I'm not holding my breath ;-)

--