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

[Stefan Puiu]

>
>
> The functional API exported to userspace isn't particularly kinky or
> wide-ranging... I'll grant you it's in the "bottom end" where the rubber
> hits
> the road where the most variations will exist. Some OSs may impose some
> requirements due to the design of their networking stack, etc, etc. I
> fully
> appreciate this.
>
> But in a post-2000 era of POSIX and all of that happy "standardised UNIX"
> userspace, I would have thought there would be some convergence in a
> library
> which is used more than almost everything except raw socket/file calls and
> the
> memory manager!


I don't think POSIX standardizes the resolver library in detail. There are
some functions, like getaddrinfo(), which are standardized, but the rest of
libresolv isn't, and can't be - as Mark said, the internal structures are
exposed in the API, so it's quite hard to write a newer, better
implementation with the old API.

Also, whenever something is not standardized, you can expect differences - I
know I've seen differences in C library functions between HP-UX and Solaris
(readdir()/opendir()), and some things are entirely system-dependent
(reading process information). Not to mention Windows - if on UNIX stat()
has some behaviour for pathnames with final "/", on Windows it's the other
way around for pathnames ending in "\", but there's also the "C:\"
exception. Not to mention that they use names prefixed with underscores for
UNIX functions. So, don't expect vendors to be benevolent and agree on
non-standardized functionality, because they won't.

>
> Well, when you say vendor, you're really speaking to the main userspace
> "C"
> library of which glibc is one large example.


As Brad said, stop thinking only about Linux, there's quite a few Unices
left out there.

> You and Stefan are misunderstanding me a bit here. I'm not asking for a
> "libbind" that lets me transparently override an installed system's
> resolver...


It was you who stated that you expected a "drop-in" replacement. So I don't
think there's been any misunderstanding on our part. Basically, that's what
you're asking, if you want apps to link against libbind instead of
libresolv.

However, you could talk to (for example) the openssh developers and see if
they would like to support building with libbind. Note that, as Paul said,
many systems will use the /etc/nsswitch.conf file before using DNS, so using
libbind would override the default resolver behaviour for that OS.

I'm asking for one which can be built and compiled against which
> allows me to AVOID using the built-in system resolver altogether. You
> don't
> need to "own" all of the various systems' resolver libraries to accomplish
> this. BIND9 aleady builds on dozens of systems (probably every OS that's
> worth using), so clearly, there is some abstraction for a great deal of
> networking and process control already there.


Check the archives - basically, what BIND 9 uses are some internal APIs
which aren't recommended for use in client applications. The resolver API is
quite complicated, more complicated than the one in BIND 8's libbind. You
have one simple getaddrinfo()/gethostbyname() wrapper (bind9_getaddresses),
the rest is tied up in BIND 9 internal structures which take some time to
understand.

Also, in order to do what you want, the replacement library would have to do
the /etc/nsswitch.conf parsing, otherwise it would break people using
/etc/hosts for some of their resolution.

And, what you don't seem to understand is that even if you'd have such a
libbind suitable for all possible UNIX platforms, it would still not be
worth much, since it's "broken by design" and not much better than what each
vendor has in their own libc.


> I'm sure there's alot of ugliness in there... there's alot of complexity
> in
> named too... and yet, that can be built and run on just about every OS in
> common use. It seems odd that we're all stuck on "BIND4" level code, for
> something that pretty much *EVERYONE* uses thousands of times a day.
>
> > You can compile the libraries yourself, and build (or rebuild)
> > programs that are compatible with those libraries and link with them,
> > but as far as covering all the other programs on the system ... well,
> > that's up to the OS developers.
>
> I understand all of this. I don't expect a magic bullet shared library
> override. I have a "ports" style build setup on my Linux systems, and in
> most
> cases, I'm most sensitive to resolver quality for the hardcore network
> services which hammer them hardest: MTAs, MUAs, etc. I'm not overly fussed
> about the resolver correctness in something like ncftp, say. But in any
> event, I fully accept that rebuilding and possibly reconfiguring would be
> necessary. THIS IS EXPECTED.
>
> I build everything I use from source and collect configure+compile scripts
> that I use (a bit like "ports" on BSD) - I'm not an "rpm" or "package"
> sort of
> guy... for one thing, I tend to not like defaults chosen by package
> managers
> - many unsafe "features" are left in place, etc. So in my case, *every*
> component of significance is built from source with customised
> configure/make
> command lines.
>
> > Take a look at the code. Note that lwresd *is* precisely the
> > same as named (it is the same source code, and the same binary), it's
> > just run with a different name, and as a result it does a few things
> > differently internally.
>
> Ah... a bit of the separation between caching/resolver DNS and
> authoritative,
> which is good sense. Though I thought that named could be configured
> easily
> to run either way, but yes, it's sensible to remove alot of crud if you
> only
> need a caching daemon.
>
> =R=
>
> PS: There's no need to directly mail replies back to me.
>
>
>
>