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.)"
Yes. As opposed to hacking any new functionality that's needed into all that existing cruft and introducing subtle, hard-to-understand bugs and security vulnerabilities. Which is the trade-off, after all.
(We don't have to stop all development on anything new in the future ever just because we have one mature codebase. It's not like we're all deploying the stuff tomorrow.)
The World Wide Web is dying. Soon, we shall have only the Internet.
nope, Microsoft has the audacity to claim their bloated buggy crap is suitable for general use.
This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs Could apply to any version of BIND
Nullius in verba
But what do you mean when you say "difficult to work with"? A code that is difficult to understand/maintain/evolve?
I sure hope not, as those are all specific design goals for the project (and they're among the failings of BIND 9 that made us want to redesign it in the first place). I meant "difficult to use" -- the user interface basically doesn't exist yet.
Tests are great for finding bug/problems you have already thought about. They are great for making sure that you don't make the same mistake again. However they don't reliably cover things you have not yet thought about. It is also really hard to write tests that cover complicated network interaction... and that is percicely what Bind must do.
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.
Is that pronounced? Does it rhyme with sinned or blind ?
Wined and dined.
BIND is thirty years old and a core piece of Internet infrastructure.
Actually, BIND 9 -- "the most popular DNS implementation on the Internet," according to the submitter -- is merely 10 years old, and was itself a major rewrite of BIND 8. BIND 8 was only declared "end of life" in 2007.
That a completely new design and re-write of such a fundamentally important piece of software is "inefficient, difficult to work with, and riddled with bugs" highlights the continuing immaturity of the computer software industry.
Really. So the fact that a software developer plans to take "the next couple of years" (again, re: the submitter) to complete a software project is symptomatic of the total failure of an entire industry. Interesting perspective. Thanks for that.
Breakfast served all day!
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 ]
One of the ideas of BIND 10 is to allow modules to be added to an already running system. Also, we want administrator tools to be able to ask the modules themselves what functionality is available. This allows relatively simple administrative tools to work with changing systems.
In order to do this, we need to have a mechanism for modules to report their capabilities. So, for example "I have a command called 'notify' which can be used to send a notify to my secondary servers, and it takes the parameter 'domain' which specifies the domain to send it from, and an optional parameter 'secondaries' which you can use to limit to a set of secondary servers".
The test code here exercises this generic capability.
[ 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...
Enforcing your copyright over original content is a bizarre license scheme? Patching considered bad? Actually doing something you promised is wrong? Public Domain is a license?
Wow, you really have drunk the DJB haters kool-aid.