[dns-operations] The Decline and Fall of BIND 10

[João Damas]

On 15 May 2014, at 04:26, Paul Vixie <paul at redbarn.org> wrote:

> 
> 
> Wayne MacLaurin wrote:
>> Bind 9.11 
>> 
>> Can’t imagine we’ll see another attempt at a ground up rebuild anytime soon…..
> 
> maybe not by ISC. but based on the success of BIND9, NSD, Knot, Unbound,
> Yadifa, and PowerDNS, i think we will see more implementations of DNS as
> time goes on. because, you guessed it, DNS is sexy.

Agreed, the next big step in DNS implementations looks to be coming from sources other than ISC at this time.

> 
> based on the fact that BIND 9.10 has a "map" file type that cuts startup
> time to "de minimis" or less even for large zones, in the same style
> long employed by NSD,

The map file type is great (I still need to open a bug report with ISC about data corruption, but that is always expected from a .0 round, no biggy), however it is not the same as NSD does, at all. The map file type is basically a memory dump of BIND’s memory representation which, as you say, is totally awesome in terms of startup time but it is not the pre-compiled answer approach of NSD.

> i think it's safe to say that BIND9 did not need a
> total rewrite as much as i thought it did when i launched that project.

Tend to agree, but for different reasons. Having been immersed in various DNS reports here at the RIPE Meeting it seems to me, as a consumer of DNS software/systems that Knot DNS is actually delivering each of the BIND 10 promises one by one, with wicked speed, the new Dynamic modules, hooks for processing, etc. It is totally awesome.
BIND9 will continue to be the main staple for quite some time as it has been proven to work throughout its long history and as Mark and Evan now master the art of banging the metal into any shape they want but I am still worried that it is showing signs of metal fatigue, same as when we decided that we needed a real refresh. Pity that went so pear-shaped, though as Shane so clearly pointed out, there were very valuable lessons in the process.

> base diversity, and i do notice that some implementors want to work on a
> common management interface so they can configure their name service in
> a standard language or protocol,

This is another good goal, particularly if we can see this be done in an incremental and modular way. Start with a few key operations that we all need and let there be vendor extensions for features that are specific to each of the servers. Trying to go to an all-encompassing solution hasn’t been working all that well so far.

Joao