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

[A Humble Bind User]

> 	BIND-4 was the second to worst "spaghetti code" mess that this
> industry has ever seen, and BIND 8 was probably the worst.  BIND-9
> was done by totally separate programmers, and not a line of code was
> shared with BIND-8.  Paul Vixie inherited this mess from his
> predecessors, and although he was the principal developer of BIND-4
> and principle architect of BIND-8, he wanted to make sure that he
> wasn't responsible for even touching a single line of code in BIND-9.

Yeah, I remember looking at BIND4 and the resulting prejudices against the
programming methodologies of UNIX software "engineers" took a decade to undo. ;)

BIND8, for all of its cruft, is the fastest of the lot, though.  But it was
definitely overdue to clean house.

> 	It's a lot harder than you think to maintain "source level API
> compatibility" across this level of development.

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!

> 	The original resolver libraries came from BIND-4, yes.  But each
> vendor has started with that and went their own separate ways.

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

> but the internal implementations may be completely different

I appreciate it's in that lower end where the differences will be most keen...
but even in a POSIX/post-2000 UNIX world, the various network socket call APIs
must surely be starting to converge?

> 	This code has found it's way into virtually every OS on the
> planet.  Do you honestly expect the BIND developers to be able to
> continue to keep ownership of all that?

No!  I would have thought that since they provide a name server which can be
compiled and run on just about every OS on the planet, that providing a
userspace library which does stub resolving with high-level APIs that match
what has been the defacto "standard" (standard enough to allow most software
making use of the calls to function without High Drama) should be possible as
well?

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

> 	You can't have your cake and eat it too.

No, that's not it.

> 	That's because you don't see all the nasty stuff that goes on
> behind the closed doors.

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.