Subject: Re: have there been any "recent" resolver fixes?
To: Andrew Brown <>
From: Michael Graff <>
List: current-users
Date: 05/25/2000 12:28:46
Since I'm a bind9 developer and avid NetBSD user, I thought I'd
explain the bind9 resolver interface a bit.

There are really three levels of resolver "support" here:

(1)  bind9 will include bind8's res_*() functions and structures.  We
     will do this by the expedient method of simply stealing them from
     bind8.  Nothing in this requires threads.

(2)  The "lightweight resolver" method lets a threaded or non-threaded
     application ask questions to get name->address or address->name
     mappings.  The daemon that answers this must (currently) be
     listening on, and requires threads.

     The purpose here is to allow vendors which already have getXbyY()
     in libc which talks to their own resolver daemon to have an
     example of how to integrate the new bind9 resolver API into their

     I have, in the past, modified NetBSD's gethostbyname(),
     getaddrinfo(), and getnamebyaddr() calls to use the lightweight
     resolver protocol.  I didn't make a shared library with it, but I
     did recompile ping, ping6, traceroute, traceroute6, and telnet to
     use it.  It worked well.

(3)  The more elaborate method is to call the bind9 libdns functions
     directly.  This will give an application the most control over
     what happens, but it is also the most complicated method.  It
     currently requires threads.

We hope to have a version of bind9 out that will not require threads,
but will basically be one large select() or poll() loop.  If someone
were to write and donate that code, of course, it would happen much
faster.  :)

Regarding threads, bind9 runs just fine on NetBSD-1.4.2/i386 and
NetBSD-current/i386 with the "unproven-pthreads" package.  For those
who don't get the joke, mit-pthreads was originally written by Chris
Provenzano, with username of "proven".  They were also referred to as
"proven's threads."  Since he's no longer developing things, but I am
to some degree, the name became unproven-pthreads.

I have been told that unproven-pthreads compiles on other
architectures as well.  I don't have the resources to test anything
other than NetBSD/i386, and to a lesser extent NetBSD/arm32 and

It is not likely that NetBSD 1.5 will have pthreads included, but the
package will continue to function on it.