BIND is the caching, authoritative DNS server that is responsible for about 90% of the Internet's DNS system, or more. A number of people dislike BIND however, and are major fans of DanBernstein's TinyDNS.

This page will be a comparison of the two DNS servers. As with most comparisons, it wont be fair or unbiased. If anything, its a rebuttal of all the pro-TinyDns fanboy whining that goes on :)

I'm pulling these points (for now) from Brad Knowle's paper on Name Server Comparison. This paper was focussed on performance of an authoritative or caching nameserver, but discusses the differences in the servers as well.

Bind 8:

Pro:

• Full recursive/caching and authoritative name server implementation
• Recursive/caching and authoritative services can share IP addresses
• Faster than Bind 9
• Wide OS Support
• statistics split by resource record type
• IPv6 Support

Cons:

• Based on Legacy (spaghetti) code
• Single-threaded
• Zone transfers handled externally (fork()/exec())
• Near End of Life
• no statistics for SERVFAIL
• uses way to much cpu for subsequent SERVFAILs

Bind 9:

Pros:

• Full recursive/caching and authoritative name server implementation
• Recursive/caching and authoritative services can share IP addresses
• Ground-up rewrite, secure
• DNS Security - DNSSEC, TSIG
• IPv6 support
• Multi-threaded, multi-proc aware
• DNS Protocol enhancements - IXFR, DDNS, Notify, EDNS0
• Standards conformant
• Split DNS / Views
• highly portable
• Internal Zone Transfer mech
• Drops privilidges, chroot()
• statistics for SERVFAIL
• caches SERVFAILs

Cons:

• Unusably slow with only several hundred recursive clients
• Seems to run into problems maintaining cache database after a while and over 250mb cached data
• statistics not split by resource record type
• more context switches due to threading compared to bind8 at same recursive workload

djbdns (TinyDNS / DnsCache?)

Cons:

• Violates RFCs
• Doesn't support zone transfers (uses optional external mech, non standarD)
• Doesn't provide referrals by default
• Doesn't support TCP by default (available with included axfrdns) (still doesn't support normal queries over TCP, just AXFRs)
• Truncates responses illegally
• Provides strange responses to query types it doesn't support (Violates the "Be liberal in what you accept, conservative in what you generate" principle)
• Without a third-party patch, cant listen on more than one IP address
• Cannot put both TinyDns and DnsCache? on the same IP (both listen on port 53 udp)
• Does not, and author's code will not, support - DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6
• Only supports limited set of record types
• Design is focussed on "fixing" security issues in Bind-8 and earlier - Bind 9 fixes these anyway
• Seems to consistently drop a small percentage of queries
• No good conversion tools from Bind
• limited hardware/OS support (compared with Bind)
• Slow. Anecdotal reports of high speed unproven. Testing by the author of this paper shows low performance
• FAST. I don't know about the guy who wrote above, but NO bind has ever managed to take on the load that is placed on the dns caches I run for a farm of over 30 mail servers. Bind 9, being the latest, took out the box immediately and a reset is required to get the box back up. Likewise, the next line is complete nonsense since Bind does not provide a single answer and at the same time takes out the box in my case. dnscache allows me to get by with just 3 boxes for dns resolution of my mail server farm. I cannot even imagine how many I need if I use Bind. Nuff said.
• Slow - Bind 8, Bind 9 30 - 40 times faster, Nominium CNS 150 times faster
• DJB has censored negative opinion of his software.

The author of this paper didn't have any positive points about djb's DNS suite, although they are widly publicised elsewhere. Some of the more salient, positive points regarding TinyDNS include:

• Adheres to 'The Unix Way' - lots of small processes doing small tasks, rather than a large monolithic approach
• Attempts to use a quicker, push mechanism for zone transfer - rsync over ssh. This isn't compatable with bind however? (however, however, it is so much smarter--use better tools to do a better job.)
• Written with security in mind from the outset.

Readers notes

As a real-world ISP owner and user of DJBDNS for years and years across dozens of machines (mostly linux), I can say DJBDNS saved our business several times over. BIND was hacked on our boxes so many times--you can imagine how painful and expensive that was! We never "got" BIND's arcane language (which reportedly can be learned only thru repeated use). How can one seriously consider BIND-anything after the incredible fiascos that were BIND 4x and 8x? The complete absence of security issues in DJBDNS was our #1 drive in switching to DJBDNS from BIND. Its dramatically increased speed was a nice side benefit. DJBDNS saved our business. It saved time and money and downtime and face. It gave us noticeably increased uptimes, simplicity and speed. If you're a zeeboid, geekoid, or flameoid, stick with BIND--you deserve each other. But if you are a straightfoward, sensible business owner who can't afford downtime or being hacked and need something that's no bullsht-get-the-job-done, then you really need DJBDNS. Some think DJB can be an ass; if that's true, I think he's earned it. I dunno DJB, don't care about DJB, but he writes GREAT software, and only a fool would dismiss it without experiencing how abruptly it blows BIND 4, 8, 9, or anything right into the weeds. BTW, qmail does for email what DJBDNS does for DNS. --Oct, 2004, from SafetyOrange?

A few comments on the above note: This page was intended as a comparison page, based on comparison of facts and analysis. Where facts are outdated, please feel free to edit the notes at the top of the page. For example, the fact that you can use axferd for TCP support is new, and worth adding. The rest of your comments are speculative or anecdotal. I'm not saying this because I instantly believe you to be wrong, or because you are in favour of DJBDNS. I'm saying it because your statements that you've "not seen" a lot of the problems with DjBDNS doesn't actually mean you weren't being affected by them, it only means you weren't observing them. The author of the original paper this page is based on conducted extensive tests into the behaviour and performance of the DNS servers he investigated, and was actively looking for broken behaviour. I personally wouldn't have a clue if the DNS servers I run were showing quirky behaviour, because I don't look for quirky behaviour - I assume they work fine, but that's all I can say. I've cleaned the original comparison points up, however you can feel free to add in any actual comments in this section. Also, can you please keep the tone of your comments level, as putting inflammatory comments (like your zeeboid one above) in here is merely a good way to get your edit reversed completely. -- DanielLawson