North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: djbdns: An alternative to BIND
On Apr 8, 2005, at 5:43 PM, Niek wrote: This actually would be an interesting list. Unfortunately, the criteria you provide are a bit hard to come up with reasonable answers for. Specifically: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: 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?- Security holes. Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.?- Amount of code What's one person's bloat is another's fundamental requirement.- Bloatness 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. DJBDNS: Yes. 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) Another easy and objectively verifiable criteria.- # of seconds it takes to load huge amounts of zones 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. 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.In the end, it all comes down to religion: Bind people don't ack djb points and vice versa. 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... :-). Rgds, -drc
|