In some email I received from Ken Hornstein, they wrote:
> 
> >> I am amused by the comment that said (paraphrased) "BSD error
> >> semantics caused DNS queries to dead nameservers to slow down", when
> >> there is code in the BIND client code that specifically does a
> >> connect on a UDP socket when only one nameserver is being queried.
> >
> >This wasn't in the version of the name resolution code that I've done
> >work on (borrowed from some version of the NetBSD C library), and
> >Alan's comment probably predates the most recentrelease of BIND.
> 
> What version?  It's definately in 1.0 (I just checked), and I seem to recall
> this behavior on Suns which use bind 4.8.3.

Currently, BIND-4.9.3-BETA17 but the final release of 4.9.3 is drawing nigh
(we've been on 17 for a couple of months or more now).

If you're running named on NetBSD then you most definately want to be
running this version instead of whatever comes with it, anyway.

>From res_send(), res_send.c:470:
/*
 * On a 4.3BSD+ machine (client and server,
 * actually), sending to a nameserver datagram
 * port with no nameserver will cause an
 * ICMP port unreachable message to be returned.
 * If our datagram socket is "connected" to the
 * server, we get an ECONNREFUSED error on the next
 * socket operation, and select returns if the
 * error message is received.  We can thus detect
 * the absence of a nameserver without timing out.
 * If we have sent queries to at least two servers,
 * however, we don't want to remain connected,
 * as we wish to receive answers from the first
 * server to respond.
 */
if (_res.nscount == 1 || (try == 0 && ns == 0)) {
        /*
         * Connect only if we are sure we won't
         * receive a response from another server.
         */
        if (!connected) {
                if (connect(s, (struct sockaddr *)nsap,
[...]

Now, on the bind mailing list, there was more discussion of what is
happening here and the right way to do it.  One comment was, that if
the ICMP error packet received matches the last packet sent to the
socket then report the error even if the socket isn't connected, else
just discard it.

Is that, perhaps, a more reasonable way for NetBSD to behave ?

darren