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.)"

Comments

Re:Great. Just what the DNS infrastructure needs

[FooAtWFU]

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.)

Re:Excellent

[rubycodez]

nope, Microsoft has the audacity to claim their bloated buggy crap is suitable for general use.

DJB might agree

[bugs2squash]

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

Re:DJB might agree

[Vellmont]

Right, much better to write code under some bizarre license, ignore it for years forcing people to distribute patches unto patches, then 6 years later finally realize you're not maintaining the code and never will and finally release it under a sane persons license.

Re:DJB might agree

[Vellmont]

(huh? Please describe)

He distributed source code, but didn't allow anyone to modify it. Thus why people distributed a series of patches to the software. People have some strange hero worship of Bernstein, but don't understand that an author who abandons his code but doesn't allow anyone else to modify it isn't deserving of much respect.

(Oh, and there are other free, open source alternatives to BIND, so saying both programs suck in different ways and better alternatives exist is perfectly valid)

Re:Difficult to work with?

[Ethanol]

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.

Re:Why?

[Ethanol]

Why would they even release it if their ground-up rewrite is so pathetic?

'Cause it's open source software, emphasis on "open". It won't be done for another couple of years, but you can look at the work in progress. You can even help write it if you want.

Re:Great. Just what the DNS infrastructure needs

[larkost]

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.

Re:Great. Just what the DNS infrastructure needs

[Anonymous Coward]

This is why you hire information/computer security researchers (or researchers in general, but security people have a tendency to think "how can I break this" as opposed to "this should work and let's all play nice") and have them review and validate your design and your code. You discuss your assumptions with them, and make sure they are sane (or can at least be enforced, i.e. buffer sizes). This is one of the most critical pieces of software that humanity will rely on for a few more decades, I think we should put some real effort into it, as opposed to an ad-hoc throw code at the wall and see what sticks.

Re:Great. Just what the DNS infrastructure needs

[Ethanol]

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.

Re:How

[Ethanol]

Is that pronounced? Does it rhyme with sinned or blind ?

Wined and dined.

Re:What's the point of a rewrite...

[Tackhead]

What's the point of a rewrite...

...if you're doing it to end up with new code that is "inefficient, difficult to work with, and riddled with bugs"?

Why, backwards-compatibility with BIND 8 and 9, of course!

Re:A Monument to "Software Engineering"

[PCM2]

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.

BIND 10 committee metings

[shani]

There is no "BIND 10 committee", but we do have weekly conference calls. Minutes from these are published on our Trac site:

https://bind10.isc.org/wiki/WeeklyConferenceCalls

[ disclaimer: I am the BIND 10 project manager ]

Why BIND 10 is a rewrite

[shani]

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 ]

Re:Why BIND 10 is a rewrite

[Shimbo]

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?

Yes, but where is Netscape today? Rwriting your code from scratch and fading into oblivion is hardly good business. Eventually the code came good but it was too late to save the company.

Re:The unit tests are a bad joke - age and sex

[shani]

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 ]

It doesn't look very understandable to me

[Chemisor]

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...

Re:It doesn't look very understandable to me

[Ethanol]

Thank you very much for looking at the code. If you could send critiques like that to the developer list instead of posting them to slashdot, it'd have a better chance of getting attention from the other developers.

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?

Actually the bit you're looking at is libdns, which we're trying to design in such a way that it can be used by other DNS-aware applications, not just BIND. (I happen to agree with several of your other points, though, and there are places outside libdns where the pimpl thing was used and maybe shouldn't have been.)

Re:It doesn't look very understandable to me

[Chemisor]

> If you could send critiques like that to the developer list instead of posting them to slashdot,
> it'd have a better chance of getting attention from the other developers

The problem is that I simply don't see what sort of "attention" I would want in such a situation. Yes, I could write up a mile-long list of complaints about the code, but it would not do any good because they would all add up to: "your code sucks; throw it all out and start over". It's not just one little thing or two little things, it's everything. It's the whole approach to interface design that plagues all open source projects and it's caused by releasing too early. Once the code is "out there", there is a chance that somebody will start using it, so you start worrying about breaking the API and inconveniencing these (often imaginary) users. If you know from the start that you intend to release early, you end up designing safety factors like pimpl into the API, in case you want to change something. I would advocate the opposite route: let the API float until the implementation settles, because you don't know how to best access the implementation until you have the implementation. And once we state our positions, there is nothing that can be done short of starting from scratch, which in not an option for a codebase many years in development.

Furthermore, my gripes have a very different focus; I care passionately about code size. To me, code simplicity is the most important goal. Simple code is easier to understand, easier to maintain, less buggy, and faster to run. I believe that code simplicity is best objectively measured by measuring the size of the resultant execuables, because "simple" should primarily mean "simple for the computer". Thus, most of the complaints I am likely to make about your code will relate to what it looks like to the computer. That's where your pimpls and out-of-line wrappers and externally visible long names all are painfully obvious. And it's also where no modern developer ever thinks of looking. No modern C++ programmer looks at the assembly his source code generates, and so he remains ignorant of where all the horrendous bloat is coming from. He doesn't understand that objects aren't real and that abstractions have costs. And from that lack of understanding comes a horrid implementation, from which then comes a horrid API.

I can complain all day about your design, but you won't know how to fix it until you understand the above problem and learn to see your code from the computer's point of view. Then I won't have to tell you what is rotten about your code, because you'll know it. Thousand-instruction functions will burn your eyes and you'll scream "but I didn't know!" and maybe then, grasshopper, will you achieve true enlightenment.

Bizzarro world of DJB haters

[Ice Station Zebra]

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.

Re:Excellent

[choongiri]

MS Office is the best DNS server ever!

You appear to be confused. DNS stands for Domain Name System, not Does Nothing Satisfactorily.