Slashdot Mirror
ISC Releases the First Look At BIND 10
Ethanol writes "Internet Systems Consortium, producers of BIND 9 (the most popular DNS implementation on the internet), have spent the past year working on a successor, BIND 10. It's entirely new code, redesigned and rewritten from the ground up, and now the first glimpse of what it will eventually look like has been released. 'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs. These problems will all be fixed over the next couple of years, as functionality is added and refined, and the software matures. However, the codebase has a good framework for moving forward, and the software is capable of serving as a DNS server with significant functionality.' (Full disclosure: I work for ISC and I'm one of the engineers on the project.)"
We wrote lots of tests. (How else would we know it has bugs in it?) This is a somewhat fair criticism of BIND 9, but read the link before you assume we didn't learn any lessons from the past. The unit tests are included in the tarball and coverage results are viewable online.
Joel has a lot of followers, but you shouldn't take what he says as holy writ. In fact, this very article is all about how we should still be using the old Netscape browser and not have started this crazy Mozilla project... you know, the one that resulted in Firefox?
I view the BIND 10 project in some ways as the DNS version of the Mozilla project - it is an ambitious rewrite, and will take a while to reach maturity. Luckily BIND 9 is still an excellent piece of software, so we have the luxury of enough time to get there.
BIND 9 is 10 years old, and was designed and implemented when the computing and Internet worlds were different than they are today. The architecture of BIND 9 - a monolithic, multithreaded program - does not lend itself well to today's DNS needs. So a new architecture is needed.
Originally we had planned on reusing a lot of the BIND 9 code. After all, like Joel says, it has been field-tested and is known to be high-quality in handling real-world DNS needs. However, the BIND 9 code has very, very high coupling. In order to make a small change or use an excerpt of code, you need to use the BIND 9 memory management system, and the BIND 9 task model, and the BIND 9 socket library, and so on. One of the reasons that BIND 9 needs to be rewritten is to make it possible to use the parts of the software you need to solve your problems without having to understand the entire system.
My theory is that the architectural problems would have been resolved over the decade of active use for BIND 9, as users submitted their patches and the developers periodically refactored the code. Unfortunately the BIND 9 project does not have an active community, either as developers or users. There are lots of people using BIND 9 (surveys put BIND 9 at about 80% of DNS servers on the Internet), but they have no group identity as BIND 9 users, and the direction and development of the software comes almost entirely from within ISC. This means it is an open source project that has resources limited in ways similar to proprietary software. If there was a BIND 9 community, then I think the software would have evolved with the times and a rewrite would not have been necessary.
For BIND 10, we want it to be an actual open source project, not just open source software. We have tried hard to be open and transparent about how BIND 10 is developed, and are trying to make it easy to participate in BIND 10. Hopefully this will be the last time a major rewrite is necessary, and the code base can evolve in any direction it needs to in the future, by maintaining a good connection with the people who actually use it.
[ disclaimer - I am the BIND 10 project manager ]
Well, I took a look at the code, and it's a typical "modern" C++ design. There's a gazillion classes in an "everything-is-an-object" hierarchy, using the latest and greatest "patterns" in superfluously complex ways. Doesn't anybody care about simplicity in design any more? Granted, BIND9 code was a mess, but this IMO is not much of an improvement. Ugly C++ is just as bad as ugly C. For example, why, for the love of God, would you replace a simple enum with a class with a member variable set to a constant value, and with each instance of the class created by a named constructor with a hardcoded constant in it? In src/lib/dns/message.h there are four of these. And what's with all the wrappers? I suppose it's their definition of "extensibility" -- a framework where everything is accessed through wrapped pimpls, so that anybody could change the implementation without changing binary compatibility with... oh, wait, it's an executable, so WTF? When you change something, you have to rebuild it anyway. So all you really get is ugly wrappers over ugly wrappers over actual code. Why do you need these wrappers anyway? What's wrong with boost's base64_encoder, for instance, that you need to wrap it with an encodeBase64 function, which instantiates a 20 line local BinaryNormalizer class in an anonymous namespace, the purpose of which, as far as I can see, is to pad the binary input with zeroes in case some evil application decides to read past the end of the vector. Oh, wait, this is only called from encodeBase64, and the read-past-the-end thing never happens. So WTF?
That's just four files I looked at, and already it's WTF piled on WTF. Maybe I ought to submit it to thedailywtf.com and see if it's accepted...