Way forward with BIND 8
Brad Knowles
brad.knowles at skynet.be
Fri Jun 6 02:43:00 PDT 2003
At 12:09 AM -0700 2003/06/06, Doug Barton wrote:
> FYI, for those wondering why I'm not considering BIND 9 for import, please
> see http://people.freebsd.org/~dougb/whybind8.html
I might be able to buy your arguments for supporting BIND 8
instead of BIND 9 in -STABLE, but not in -CURRENT.
BIND 9 is the future. BIND 8 is ancient spaghetti code that only
kinda-semi-sorta holds together, and there is only one guy working on
maintaining it during the turn-down phase to EOL.
BIND 9 uses new secure programming techniques that cause it to
apply near-paranoid checks to data inputs and intentionally crash if
it finds anything amiss. This helps ensure that almost all major
input bugs are found and fixed before the code ever leaves the ISC.
There's no sense re-hashing all these issues in e-mail -- I've
got a whole host of reasons why BIND 8 is bad, and why BIND 9 is
better. See slides 66-72 of my talk _Domain Name Server Comparison:
BIND 8 vs. BIND 9 vs. djbdns vs. ???_, as presented at RIPE 44 in
Amsterdam (at
<http://www.shub-internet.org/brad/papers/dnscomparison/DNSComp-RIPE44.pdf.gz>).
Also note that if you're going to flame someone for development
on BIND 9, you shouldn't be flaming Nominum. They no longer do any
work on BIND 9, and some of the people who were doing that work have
been transferred to work directly for the ISC (as opposed to doing
the work as Nominum employees under contract to the ISC).
Indeed, even when Nominum was doing development on BIND 9 under
contract to the ISC, the ISC still controlled the direction of the
development and the overall manner in which the code would be
written, with Nominum handling the implementation details.
Therefore, even if you had these complaints years ago, you should
still have addressed them to the ISC, not Nominum.
Anyway, the argument for having separate -STABLE and -CURRENT
branches is so that development on new code can progress, and
adventurous types can give the new stuff a try (and help debug it),
while less adventurous types can stick with tried-n-true.
If you believe this argument at all, you cannot possibly justify
keeping BIND 8 in -CURRENT.
Virtually everything negative you have to say about BIND 9 is
something that could also be said of -CURRENT. How do you expect
that we can ever arrive at a -STABLE without first having a -CURRENT?
Well, the same is true for BIND 9.
Indeed, I'd say that BIND 9 is much more mature and
production-ready than -CURRENT is most of the time (situations such
as the current transition where we're just about to make 5.x the new
-STABLE being the one exception I can think of).
--
Brad Knowles, <brad.knowles at skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
More information about the freebsd-arch
mailing list