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.)"
Is that pronounced? Does it rhyme with sinned or blind ?
Slow, buggy, hard to work with, but we'll fix it later. And not Microsoft?
So we're throwing away all the code that has matured and spend a decade being looked at, and starting over with new buggy code that will be riddled with security vulnerabilities.
Nice.
If you need web hosting, you could do worse than here
No djb tag?
I want to delete my account but Slashdot doesn't allow it.
Why would they even release it if their ground-up rewrite is so pathetic? Were they worried that BIND might be losing its rich reputation as the worst piece of widely-used network software ever made? If so, bravo, guys.
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.
This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs
Inefficiency and bugs are common characteristics of alpha/beta code. But what do you mean when you say "difficult to work with"? A code that is difficult to understand/maintain/evolve?
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
Seriously. "Riddled with bugs"? The implication is that nobody at ISC knows how to write good software. Not really surprising. Bind 4 was a mess. Bind 8 was a mess. Bind 9 was a mess.
"Insanity: doing the same thing over and over again and expecting different results." (Einstein)
They need to start over using sane software design methodology. That probably means hiring competent software engineers.
BIND was the joke of the security conscious community for over a decade. I look forward to their new code. Maybe we can return to the good old days.
'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs.' Why does this statement make me so happy?
I thought bind 9 was a rewrite from scratch? They did such a crappy job, they have to do it again for 10?
//m
Simply: I wonder what they find so hard about writing tests.
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.
How's the old, GIGO phrase go....
So if you start with the same old stuff in (BIND symantics/syntax), use some "new" code to processes it, and you expect the post dump analysis to be different irrespective of how much the code is rewritten to generate the S.O.S?
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.
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.
Yes, yes, we realize djbdns is far more secure. And that DJB is ornery.
Instead of peppering the whole forum with "djbdns is great", just respond to this thread.
Frist!
...if you're doing it to end up with new code that is "inefficient, difficult to work with, and riddled with bugs"?
Was the original code too efficient, well-commented and well-tested and they couldn't live with that?
BIND is thirty years old and a core piece of Internet infrastructure. 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.
This should be an embarrassment to every software designer, Google, IBM, and Microsoft should be screaming out how this is making the entire industry look bad.
Wouldn't this be an ideal target for test driven development, or are we to praise that at least they aware of defects?
I'm not in a rush for bind10 - I find bind9 to be quite sufficient, on the whole. I do look forward to seeing what it brings and how it may make my life with the systems I manage much easier. This does look interesting though!
So instead of 1 daemon I'll now get 3-4 running daemons interacting in strange ways? Thanks, that's exactly what I need.
How about scriptability and/or custom resolvers? Nope, none of this.
Oh well, probably I should switch to DJBDns. It also uses a ton of daemons, but at least it's architectured properly.
If everyone subscribed to that logic, we would not have Postfix, Firefox, lighttpd, or any other number of important open source Internet software projects.
They rewrote it from the ground up *again*? Clearly the last few times they did that didn't help. Why should this time be any different?
both Firefox and lighttpd started out as very small subsets of larger tools, focusing on small code and a lower number of features. From the sound of BIND 10, it sounds like they're shooting for the universe.
Also, Postfix wasn't a rewrite of existing code.
If you need web hosting, you could do worse than here
In my opinion, if you're going to start over, you start a new project. You start small, and you build a solid base of code. You don't get something that the authors admit is "riddled with bugs"
If you need web hosting, you could do worse than here
"Architecture" is a noun. "Design" is a verb (or a noun). There's no "architectured".
It responds with an IP address given a name.
How exactly is that "complicated network interaction"?
Yes, yes.. i know, we have Dynamic updates, DNSSec, etc.. now.. but come on, how hard is it to get the basics solid, then move on to the rest?
If you need web hosting, you could do worse than here
relax, it happens sometimes: for example when a major version is created...have you ever heard the term "alpha code"?
Turned you down, did they?
"matured" indeed. bind is known for carrying plentiful amounts of exploits to the point of MS Exchange/IE. It's coders must be basement dwellers because by now they should know how to create and follow a process.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Most of the trouble with BIND stems from the fact that it's a database app with its own database implementation. BIND10 uses SQLite, which already works. That ought to simplify the thing enormously.
Building in a web server for BIND administration is probably the source of much of the complexity.
These problems will all be fixed over the next couple of years
I admit complete ignorance in this area, so please educate me if this sounds stupid -- but surely writing a DNS server can't be that hard?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Which major features in bind9 are going to be thrown out (and stay out even beyond beta) for bind10?
Dynamic updates, DNSSec/etc. are part of the basics nowadays.
hiring people isn't a solution to anything.
That's like asking someone to figure out how to prevent a situation that has never occurred.
you can plan and plan and plan, but you're not going to have a fallback for everything that can possibly happen.
How do you sleep knowing DJB is out there and you can't compare? How can this be your 10th version with no hope of being better at writing DNS code. Swallow your pride, and start with a known good code base, you know like DJB, then cock it up... you are bind after all... that's what you guys do, and that you ARE good at. Every week, every month for years, decades, it's another bind security alert. Bind is the only code that I know of that is the exception to the saying "you can't make a silk purse out of a sows ear"... you can if there is no ear left, is there any original code in b9? Back to the drawing board wasn't far enough... jesus christ. Are interns the only ones allowed to code? Are you getting M$ rejects? I don't understand, do the opposite of what you think you should do, and maybe you have some decent code there, ask people on the street if this this and this are a good idea... ask your grand parents, filp coins... something other than what you do day in and day out fuck! -rich
If you can't write a new program, practically free of buggy code, you certainly don't have the wherewithall to fix bugs in existing code...
Sendmail certainly came through it's rewrite vastly better than it was before. Other DNS programs, like MaraDNS, have come on the scene, and remain exploit-free for several years now.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Dude, you have fucking got to be joking!
155 // should we refactor this code using, e.g, the state pattern? Probably // not at this point, as this is based on proved code (derived from BIND9) // and it's less likely that we'll have more variations in the domain name // syntax. If this ever happens next time, we should consider refactor // the code, rather than adding more states and cases below. // // Is this the root name? //
156
157
158
159
160 while (ndata.size() 161 unsigned char c = *s++;
162
163 switch (state) {
164 case ft_init:
165
166
167
168 if (c == '.') {
169 if (s != send) {
170 isc_throw(EmptyLabel, "non terminating empty label");
171 }
You have variables name like "s" and "c" and you declare and init a variable inside a while loop, and assign it the incremented value of a dereferenced pointer!?
I know you inherited this code from the comments, but unless someone is physically preventing you from changing it you have no business writing any code that is critical to the functioning of the internet.
Hey KID! Yeah you, get the fuck off my lawn!
Seriously? The idea is to go for yet another rewrite? And it sounds like it's going to be a half-assed database backing (SQLite? Is this right?)? Why not just move to an abstracted storage backend, and let the admin pick what works for him (or write his own backend plugin)? You know, like PowerDNS has been doing for awhile now. Seriously, guys, let's just stop using BIND and move to a better nameserver; it really seems like ISC is going to be rewriting BIND until the heat death of the universe.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
If they didn't get it right after nine versions then it's probably time to move on.
"...is known to be inefficient, difficult to work with, and riddled with bugs"
Make that "definitely".
No sig today...
Short variable names are fine, as long as their scope is limited. Do you prefer "index" to "i", for example? Such names are common.
So? If it's only used in that block, why on earth wouldn't you declare it in that block? Scope. It's a good thing.
Do you program in C? A construct like *s++ is really very common. K&R, for example, give the following strcpy() example (not an ANSI/ISO implementation, but it doesn't matter):
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}
Or do you have a problem with using something like that as an initializer? Why?
You, personally, might not like the style, but you can't pretend it's somehow "incorrect".
Something as simple as DNS should have been "right" after about version 3.
Version 10 being a complete rewrite and still "inefficient, difficult to work with, and riddled with bugs" is funniest thing I've heard this month. I can only imagine what the committee meetings for this are like.
No sig today...
Yes using i is a common idiom in C when using a throw away integer for loop control, its intent is clear,
In this code ( please go read the rest of it ) the variable c referes to s all over the place and these is nothing really explaining it. While being terse does have its merits as the example you showed indicates ( the scope is limited to a simple 5 line function, that kind of terseness does not belong spread over 50 lines of code.
As an initializer you really have no idea what you are initializing with unless you are intimately familiar with the code, and yes I have done such in many instances but with a variable name that gives some hint ( at least ) as to what it does. This is just plain bad coding.
Hey KID! Yeah you, get the fuck off my lawn!
Sure - new codebase, new bugs. A given. What isn't given is why the original developers thought this was a good idea? None of the answers to that question that I can think of are complimentary to what is now core infrastructure to the Internet. Was it not modularly written? Was it horribly insecure, and so badly so that it wasn't considered worth extending?
Bind is now in its tenth revision. You'd think by now that some sort of good, workable framework or design pattern would have evolved by now?
But clearly, it hasn't, and clearly, after several rewrites, it's *still* not considered worthy of being extended or refactored rather than rewritten. This bespeaks (to me) a well of WTFs, in light of the idea that you should basically never rewrite your software .
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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 ]
These tests are a joke, for example in the file src/bin/bindctl/unittest/bindctl_test.py we have the following function (which isn't used anywhere, so what is the point of this test function, Bind will support some sort of age/sex restrictions on data it serves perhaps?):
class TestModuleInfo(unittest.TestCase):
def test_get_param_name_by_position(self):
cmd = CommandInfo('command')
cmd.add_param(ParamInfo('name'))
cmd.add_param(ParamInfo('age'))
cmd.add_param(ParamInfo('data', optional = True))
cmd.add_param(ParamInfo('sex'))
self.assertEqual('name', cmd.get_param_name_by_position(0, 2))
self.assertEqual('age', cmd.get_param_name_by_position(1, 2))
self.assertEqual('sex', cmd.get_param_name_by_position(2, 3))
self.assertEqual('data', cmd.get_param_name_by_position(2, 4))
self.assertEqual('data', cmd.get_param_name_by_position(2, 4))
self.assertRaises(KeyError, cmd.get_param_name_by_position, 4, 4)
I seriously get the feeling they padded out the unit tests with.. well.. junk from who knows where.
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 ]
The design for BIND 10 allows for generic back-ends. We implemented SQLite as the first one, simply because it was the easiest. One of our early goals for the second year of development is to support additional database back-ends (we call them "data sources"), including MySQL, PostgreSQL, and an in-memory 'database' (for performance-critical environments).
In the end we'll also support more exotic back-ends, like BDB, LDAP, directories, and possibly even the tinydns data format.
[ disclaimer - I am the BIND 10 project manager ]
'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs.'
If this is indeed a true statement this code is doomed and should be thrown away right now.
If they don't do it right from the start they will spend the rest of forever turd-polishing.
Using "s" to refer to a string and "c" to refer to successive characters in it is a common C idiom, and will be immediately understood by any competent C programmer.
You'd model it and apply LTL to check for certain classes of bugs.
You mean like Windows ME? ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
There's no mention of the bloat of BIND9. Will it be carried into BIND10? Are they reimplementing all the bloat from the ground up?
I'll stick with NSD and Unbound.
now we need to go OSS in diesel cars
I'm going to say that s and c are a string and a character, respectively, as s is being treated like a pointer to an array of characters. That being the case, these names are exactly as idiomatic as i.
People are really complaining too much about having a buggy BIND 10 implementation. This is alpha software, with a long life cycle. This software will be expected to last years, so taking a few to make sure all the bugs are ironed out properly is not a big deal. As far as I can tell the development team is approaching this the right way.
Is there still a lot of Bind users out there?
NSD and Unbound are way better, but they aren't the only worthy alternatives.
{{.sig}}
DNS for IPv6 will have to know a whole lot more about which address to dish out 1st than current versions of BIND and I'm not sure how long it will take to get a good handle on that problem.
I'm old school so I like dedicated hardware for my DNS servers. I run bsd jails that don't have anything but bind running. I used to run solaris servers that had init running named running off a read only scsi disk that was shared with another server. Init ran another program that would mount the file system read only, copy the zone files and then unmount the disk. There was another program that watched for a condition and then sent init signals. There were less than 20 files on the disk. That is what I want on a future name server. I can do that now on a Freebsd zone or a Solaris container as well (except I have to replace iniit with the cd rom boot one, why does it link to buggy xml libs?)
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...
I'm assuming s and c are part of the idiom in this code. And it's good practice to declare variables in the smallest possible scope, and init them at the same time. It sounds like you think it's inefficient, but any decent compiler will optimize away 'c'; it's only there for readability.
I'm more worried by the mention of "patterns". And by the C++-style comments, which prevents the code from being compiled as good old ANSI C. Hopefully they use the *useful* C99 features too.
I switched to PowerDNS a long time ago and never really looked back at Bind. PowerDNS is awesome. It is fast, modern and has much less of a buggy/exploity reputation as Bind has.
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.
I mean for chrissake, how hard can it be to take a domain name and return an IP, and vice versa? It's a database with a coupla queries. Sheesh. And why churn out code that is full of security vulnerabilities? A security vulnerability is a shitty piece of code. Plain and simple.
Looking at the posted code, it's pretty obvious that s is the input string being parsed and c is the next character being read. I would expect the rest of this function to contain a switch statement providing cases for the next character.
The point of longer variable names is to make the code easier to read. If someone with C experience can look at the code and know what it's doing, then this goal is achieved already.
If I were writing this code, then I'd probably use a parser generator like LEMON rather than writing the parser by hand, but given that his is the record parser and the grammar is pretty simple, I might not bother.
I am TheRaven on Soylent News
ha! where are my mod points when I need them?
Actually I'm pretty sure BIND 9 was advertised as a near-complete rewrite too.
That said, I'm not touching either version ever again after using http://cr.yp.to/djbdns.html
- Michael T. Babcock (Yes, I blog)
That's arguably why DJB wrote tinydns -- do the simple things well and correctly.
The caching resolver portion however is what allows for cache poisoning attacks and some other interesting Internet security holes in the last decade.
- Michael T. Babcock (Yes, I blog)
Why are you writing it in C/C++??
If you need an important infrastructure system to be as known-good as possible, there are much better choices. (Ada is even part of the gcc, and so is portable across a wide range of architectures.)
"I don't know, therefore Aliens" Wafflebox1
you declare and init a variable inside a while loop, and assign it the incremented value of a dereferenced pointer!?
What's your problem?
The variable is probably declared there for readability/maintenance purposes, and the compiler will re-organize that anyway.
You obviously don't understand operator precedence because that code does not assign it the incremented value of a dereferenced pointer, it takes the value of the derefenced pointer and then increments the pointer, as you might do if "s" was being used to walk an array.
you have no business writing any code that is critical to the functioning of the internet
You have no business making such assertions. You clearly didn't take two minutes to try to understand this code before lambasting someone over it. A logical train of thought may have started "that code is most likely correct because it's been used without problem in BIND for decades".
P.S. Moron.
The C++-style comments aren't the only thing that will prevent it from being compiled as ANSI C--the code being written in C++ might prevent it, as well :-)
And it's good practice to declare variables in the smallest possible scope, and init them at the same time.It sounds like you think it's inefficient, but any decent compiler will optimize away 'c'; it's only there for readability.
I'm more worried by the mention of "patterns". And by the C++-style comments,
which prevents the code from being compiled as good old ANSI C. Hopefully they
use the *useful* C99 features too.
Uh... declaring and initializing variables inside a while() statement is not compatible with "good old ANSI C." Can't have it both ways. Though it is 2010 now, maybe comments which work with C99 is okay now?
Better yet, just use C++. It's not a driver, or even a library, it's an app. Using proven STL libraries will clearly improve the code quality and security.
Actually, maybe it is C++, as if 's' is a string, then "s != send" indicates 's' is actually an instance of a string class, not a char pointer. (I didn't look at the full code, just the snippet posted)
Yup, that's why I insisted that for my security relative, impossible to update (embedded) software a specialized test team was created. I would not be surprised (actually I'm quite sure) that the test costs are about 10 times that of development.
But even that does not solve the problems with testing. Because the test team needs to consult the development team/domain expert and requires to take the architecture/implementation in mind, many tests will *still* only cover those already envisioned by the development team.
In the end, you'll have to throw it in the pond and see if it floats. Of course, a highly complex, temporary pond is the best for ironing out the ironic bugs still present after development testing. Of course, the issues that are found should become part of the software tests, if only to prevent regression.
You are over-generalizing as much as the GP. Hiring people is a great idea if they have more knowledge on a subject, especially while testing. They will find bugs and even architectural errors before you start to test in the field. They won't find every bug, but alpha/beta testing certainly won't find all bugs either. In the end there will always be gamma bugs left (that you find by, eh, field testing). The trick is to iron out as many of them as you can find.
As long as the context of s and c is understood (in other words, if they are part of a local loop without any other variables that could become s or c) then that is fine. Even then I personally believe that verbose variable names are better, if only because it lowers the learning curve.
Because they did not *completely* rewrite it it seems. They know there tools, they probably have made the decision to go without Garbage Collection. There could be many many other reasons.
BTW, this is the wrong thread for this discussion. Even so, people are entitled to their meaning mods, modding this flamebait is taking it a bit far.
Sorry for OT top-posting, but I must ask this. What is the standard procedure for proposing a protocol extension (DNS more specifically)? My idea is simple - it relates to IPv6 networks. When a DNS server supporting the protocol extension (and has it enabled) receives a query that resolves to a v6 address, transforms the address to a address mapping pushed to the NAT-ing edge router via IGDP, receives the internal v4 address, and returns it as a result to the original DNS query. I think the point is quite clear. What does /. think?
I know tobacco is bad for you, so I smoke weed with crack.
Actually, we did have a look at PowerDNS. I did a project with it at my last job. PowerDNS is not perfect, but it has a few good things that we want to also have in BIND 10. The generic back-ends is one, the fact that the code can be understood and fixed by a skilled programmer within a few hours instead of a few days is another. I also like a few "nice" things from the command line tools - although of course some choices are a bit broken.
While administrators will have to choose the best DNS software to fit their needs, I don't actually view it as a competition. In fact, a diverse code base is good for the Internet ecosystem. It limits the impact of bugs, exploits, and general design artifacts.
But be sure to use BIND 10 when it's ready for production. ;)
[ disclaimer - I am the BIND 10 project manager ]
Where's the fearless boy wonder Dan Kaminski? He's been busy abusing and breaking DNS for years! How about him getting off his ass and actually building something for once? It's easy to destroy something but it's much harder to create something worthwhile.