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

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.

  Latest articles

Strange / Frustrating Caching Problems

Slave bind skips delegation record in master zone

Slave zones not updating

SPF RRType

Trying to get full domain info in nslookup

bind secure architecture