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

Brad Knowles brad at stop.mail-abuse.org
Mon Oct 17 12:35:39 UTC 2005


At 9:11 PM +1000 2005-10-17, A Humble Bind User 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.

	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.


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

	Would you honestly expect Linux to do this with the pre-1.0 
versions, as compared to the latest 2.6 kernels?  After all, that is 
about the same timeframe of development we're talking about here....

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

	The original resolver libraries came from BIND-4, yes.  But each 
vendor has started with that and went their own separate ways.  Yes, 
there is API compatibility at a very high level (the old routines 
have the same names and the same arguments, and most everyone has 
switched over to using the new names for the new routines, with their 
new arguments), but the internal implementations may be completely 
different, and where in the library system that code is be placed may 
also be completely different.

	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?

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

	You can't have your cake and eat it too.  Either the vendors take 
the original stuff from ten or fifteen years ago (or whenever) and 
then run with it and maybe they periodically check in to see if there 
have been any major improvements, or the BIND developers shoulder the 
responsibility for continued development of the libraries for every 
single OS that has ever been created over the past ten or fifteen 
years, plus all possible future OSes.

	But it's either one way or the other.  You can't have both.

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

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

>  The situation sounds worse than I feared.  Upgrading system 
>resolver libraries
>  is basically up to the core glibc folk...

	Yup.  It is called "systems programming" for a reason.

	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.

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

	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.

	If you run a local named on each client, then I would expect that 
you don't need an lwresd -- that's only for use in more specialized 
circumstances where you "can't" run a local named on each machine, 
but you still need some of the critical features that named provides.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.



More information about the bind-users mailing list