named 8.3.4 dies under recursive cache load (with ACL'ed zones?)

Paul Vixie paul at vix.com
Sat Feb 15 20:44:09 UTC 2003


> > Out of curiosity, what features are those?
> 
> Well, I've been talking about these things for several years now.  They
> boil down to production and operational features that I use on a daily
> basis in BINDv8:

here's my recommendation.  file specific, detailed, objective bug reports
on everything you need from bind that bind8 does and bind9 doesn't do.

that goes for all of you here on bind-workers, not just greg.

> 	- several logging mis-features (channels are unchangable until
> 	  after named.conf has been read in its entirety, for one)
> 
> 	- cannot even be optionally configured to enforce RFC 952
> 
> 	- cannot keep track of very host that it interacts with
> 
> 	- caches cannot keep track of where they learned RRs from
> 
> 	- does not keep track of and report other useful runtime statistics
> 
> 	- no AF_LOCAL (i.e. AF_UNIX) control channel support for rndc
> 	  (I don't need or want any remote control access!)
> 
> 	- serious ongoing security bugs with PID file management (and
> 	  though I and others have patches that seem to fix these bugs,
> 	  they've been ignored to date)
> 
> At least now finally in 9.2.x rndc is almost useful and usable, so
> that's one down!  ;-)
> 
> I'm sure there are other things I'm forgetting too....

file bug reports.  we will add features to bind9 as necessary to make it
compatible with bind8.  some things, like performance, will take longer
to fix.  some things, like rndc, you're going to have to use workarounds
for (AF_INET 127.0.0.1 is a functional equivilent for AF_LOCAL, and is a
whole lot more portable -- remember that many systems *STILL* do not 
enforce file permissions on unix domain sockets, so keys MUST be used.)

> > Actually, if there is a bug in BINDv8 as you suspect, then going to 
> > BINDv9 would probably help given that there is essentially no shared 
> > code between BINDv8 and BINDv9.
> 
> Yup, let's trade one set of known bugs for another set of unknown bugs!  ;-)
> 
> I appreciate that lots of people are relatively happily running BINDv9,
> but I'm not near ready to yet myself, except of course on the test
> servers where I keep my hopes up trying out new releases.

we're running bind9 on f-root and ns-ext, and all of our recursive servers,
and we pound the hell out of all of them.  of unknown bugs, i suspect that
there are still more in bind8 than yet in bind9.

> I also appreciate very much that code doesn't write itself and that the
> programmers who do write it (including myself!) like to get compensated
> for our efforts.

thanks to the members of the bind forum, we have compensation enough to
keep putting out maintainance releases, and sometimes we can sneak in some
features as well.  and, thanks to interested vendors and users, we have
periodic development contracts for occasional major feature expansion.  we
would do more of both if we had more forum members and more development
contracts, but the numbers are measurably non-zero today.

> I am surprised though that many of these production and operational
> features have not yet been added to such a widely used piece of
> production software.

your past complaints have been a bit nonspecific.  complaints which were
more detailed and more objective have already been addressed or are in the
queue to be addressed, pending resources.  please tell us exactly what you
need in order to make bind9 more useful to you than bind8 is/was, and we'll
make sure it happens, pending resources.


More information about the bind-workers mailing list