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

Stefan Puiu stefan.puiu at gmail.com
Mon Oct 17 12:06:40 UTC 2005


Ok, time for a disclaimer: I'm not a libbind or BIND developer, I've just
been using libbind to some extent and I'm familiar with some of its issues.
I can't speak for ISC, and I'm not trying to - I can at best try to guess at
the motivation of some developments.
I think you fail to understand something: in order for users to have the
ability to replace their own resolver library, you'd need to make all UNIX
vendors agree to support this, and make them help the BIND developers make
their libbind usable instead of their own libresolv. However, as far as my
copy of "DNS & BIND" tells me, each vendor chooses whatever resolver library
version it wants, and modifies it to suit its own purposes. So, with this in
mind, you can understand that there is no way right now that libbind can
keep track of all these additions. I think whenever there's a libresolv
exploit (there have been a few in the past), each UNIX vendor provides a
patched version for their OS. The same with Linux.

So basically, if you have up-to-date patches, you don't need to worry about
replacing libresolv. I don't think there are less chances to find holes in
newer libbind libraries than the old libresolv.

libbind9 is a very small library, as of 9.3.1 it offered configuration file
parsing and a simple getaddrinfo() wrapper - don't remember if there was
anything more. It might be intended to supersede libbind, but it's still far
from achieving that. I don't think any of the libbind functions is
implemented in libbind9 yet, so don't rely on it.

liblwres is meant to be used with the lightweight resolver daemon, I think
you can check the ARM for more details; I won't try to summarize it from
memory.

You have to remember that libbind's initial design was not exactly
threading-friendly, hence the need of res_nXXX() functions, so people might
not want to maintain the old interface; the higher levels (res_search(), for
example) might be manageable, not the rest. Also, the way those
res_nmkupdrec() & friends functions are designed (and the structures they
use) are just inviting you to write code that leaks memory like hell.

On 10/17/05, A Humble Bind User <bindmail at paypc.com> wrote:
>
>
> 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.


I had hoped that those responsible for defining various resolver APIs (the



We all have hopes, and we sometimes end up dissapointed. Maybe others on the
list can provide us better insight about why this was not possible, but bear
in mind that every UNIX vendor has its own requirements for their resolvers,
so they end up hacking some version of libbind and maintaining it in-house.

>
> 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?


Not that I know of.

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.
>

Yes, I'm afraid you have misunderstood something. basically, BIND9 is
rewritten from scratch, but there isn't anything similar to libbind offered
using the new code yet. libbind9 might be an attempt at that (somebody from
ISC might comment), but it's nowhere near that yet (haven't checked the
9.3.2 beta, though).



More information about the bind-users mailing list