North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: djbdns: An alternative to BIND

  • From: David Conrad
  • Date: Sat Apr 09 04:15:36 2005

On Apr 8, 2005, at 5:43 PM, Niek wrote:
On 4/9/2005 1:50 AM +0100, Paul Vixie wrote:
  Count Server Software
[snip some list]
One could also put together a list based on:
This actually would be an interesting list. Unfortunately, the criteria you provide are a bit hard to come up with reasonable answers for. Specifically:

- Security holes.
What do you count as a "security hole"? BINDv9 is a completely different code base than BINDv4 or BINDv8. Should security holes in earlier versions of BIND count against BINDv9? Since tinyDNS requires the use of rsync (or similar) to transfer zone data to secondaries, should security issues in that package count against tinyDNS? How about syslog?

- Amount of code
Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.?

- Bloatness
What's one person's bloat is another's fundamental requirement.

BIND, since it tries to be a reference implementation of the DNS protocols, includes pretty much everything the IETF standardizes on. DJBDNS doesn't attempt to be a reference implementation, so many of the features and/or functionality available in BIND are simply not there. BIND has a very long history of features and functionality that have been added as a result of operational experience, e.g., BIND's logging system, blackhole functionality, views, etc. DJBDNS relies on external programs to meet these operational requirements (of some).

- Seperation of functionality
An easy and objectively verifiable one:

BIND4, 8, 9: No.

To add some others:

Microsoft DNS: No.
MaraDNS: No.
NSD: Yes (authoritative only)
PowerDNS: Yes (authoritative only)
Posadis: No.
MyDNS: Yes (authoritative only)

(I might have gotten some of these wrong)

- # of seconds it takes to load huge amounts of zones
Another easy and objectively verifiable criteria.

DJBDNS is faster in loading huge amounts of zones.

Of course, one could argue that loading huge amounts of data is not something you'd typically want to do, so optimization should be spent in what a DNS server does do frequently (i.e., answer DNS queries) but that could be a value judgment.

In the end, it all comes down to religion:
Bind people don't ack djb points and vice versa.
Actually, I don't believe this is true. There are a wide variety of objectively verifiable metrics folks can use to determine which DNS server best meets their needs. Throughput (queries per second), latency, forwarding time, standards compliance, data load times (many zones, big zones), stability/reliability (how often does it crash), availability (how often does it takes naps), memory consumption, CPU consumption, etc.

Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war since I work for a company that has created a product that could be argued competes with both... :-).