Date: Fri, 6 Jun 2003 11:32:56 +0200 From: Brad Knowles <brad.knowles@skynet.be> To: freebsd-arch@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: Way forward with BIND 8 Message-ID: <a06001214bb060a199205@[10.0.1.2]> In-Reply-To: <20030605235254.W5414@znfgre.qbhto.arg> References: <20030605235254.W5414@znfgre.qbhto.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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(+++)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a06001214bb060a199205>