restructuring/redesigning BIND (was Re: 9.2.5 db causes high cpu?)

Paul Vixie paul at
Tue Feb 22 21:04:50 UTC 2005

> > there's already excellent separation between the mainline and the
> > various modules that provide the various functionality.  we just
> > don't put functionality into user-specified *.so files the way
> > apache2 does.  (note that i'd like us to do this for things like SQL
> > and other backend support, but not for things like protocol
> > processing.)
> Ah, that was my main point, splitting things out that is.  I'd think a
> 'baseline' BIND named without any "new fangled stuff" should be quick
> to startup and more secure than a BIND that incorporates the
> in-progress items like TSIG and IPv6.

named in BIND9 starts up pretty quick, if you mean "starts to read its
zone files", or even "starts to answer queries" if you don't have a lot
of zone-data to read in.  demand paging makes the size of your binary
pretty much irrelevant as i'm sure you know.

> > (also note that since "named" is the only client for most of these
> > libraries, the in-core savings from "--enable-shared
> > --enable-libtool" is nonexistent.)
> Well, likewise for Apache, mmm?  The point being much more about
> security and restricting/abstracting featureset than reducing core
> size.  Pieces like the DLZ work and other database-backend plugins
> should be simple .so additions, not the patch-o-rama it is today.  

now that the apache2 people have done the hard work of figuring out now
to do "DSO"'s on many different systems, i am ready to agree with you
for things like DLZ.  "define a plug-in architecture" was on the roadmap
draft i last saw.

More information about the bind-workers mailing list