Odd problems trying to make use of libbind as a replacement resolver...

[A Humble Bind User]

> Your assumption is wrong - a lot (if not all) of the UNIX C libraries use
> code from some version of libbind - almost always an old version. 

I know this.

> I don't
> know how up-to-date the glibc manual on my machine is, but it says: "The
> DNS resolver code is taken directly from BIND 4.9.5". 

I think that's where Herr Drepper forked it for libresolv, yes.

> Now, you realize that
> since BIND 4.9.5, a lot of things changed, so you realize you can't expect
> backwards compatibility going that far.

Given that it's been maintained by a small core of people (the "Cathedral"
model seems to be in effect for the ISC code) who've had the entire historical
perspective of its developers, source level API compatibility should have been
manageable.

> The "was designed as a drop-in replacement" is wrong - the BIND people 
> can't maintain drop-in replacement libraries for the various UNIX
> configurations out there. 

I had hoped that those responsible for defining various resolver APIs (the
glibc and other such library maintainers usually derive their own work from
others') would have defined a core set of resolver functions at various levels
of functionality (threaded versus non-threaded, etc).  I'm not expecting to
take advantage of super-spiffy async event-driven multi-request resolver
functionality to be available through 15+ year old resolver APIs, however I'm
hoping that there are more robust and resilient (as well as possibly more
configurable via /etc/resolv.conf) libraries which provide source API
compatible resolver functionality.  In short... a resolver library which is: 

o) Actively maintained
o) Not painful to upgrade when vulnerabilities/flaws arise
o) And ideally, one which is closely tied to the development of what is no
doubt the most commonly used authoritative name server software on the Internet.

After all, it doesn't seem problematic for most resolver-using userspace code
to work on a variety of platforms, so such an API is at least generally
agreed-upon in practice, if not in principle.

I think DJB's taken a stab at such a replacement library, though I realise his
name's a bit of a dirty word in some parts.

> Is this assumption based on documentation, or just a supposition
> of yours?

Call it hope.

The situation sounds worse than I feared.  Upgrading system resolver libraries
is basically up to the core glibc folk...  for this reason, it would seem that
it's more important than ever to have a replacement library which emerges as
the defacto resolver library of preference for name resolution.

What exactly is libbind/libbind9 meant for, then?  lwres seems to aim to
provide "slip-on" replacement support, but that's a bit of a strange bird that
involves running yet another daemon on the machine.  If I already have caching
nameservers on my busy servers, the overhead of the extra communication
client-->lwresd-->named-->lwresd-->client seems oddly wasteful.

> I would stay with glibc for now. libbind is dead code, too, if you look in
> the source you'd see it's not exactly modern (even though it could be
> better than what's in glibc).

OK, so IS there a better/more-up-to-date/actively maintained resolver library
which at least pretends to offer a reasonable amount of source-level
compatibility for userspace applications on UNIX systems?

I'd love to make use of the "all-new" code reviewed BIND9 quality but in a
resolver library... and it sounds like this doesn't exist.

=R=