Re: Way forward with BIND 8

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(+++)