Penguin
Note: You are viewing an old revision of this page. View the current version.

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 too 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 (anecdotal?)
  • Seems to run into problems maintaining cache database after a while and over 250mb cached data (anecdotal)
  • statistics not split by resource record type
  • more context switches due to threading compared to bind8 at same recursive workload - only applies if you run it in threaded mode. The default is one thread.

djbdns (TinyDNS / DnsCache?)

Cons:

  • Violates RFCs
  • Doesn't provide referrals by default
  • TinyDNS Doesn't support TCP by default (available with included axfrdns which supports both authoritative queries and zone transfers). DNSCache does.
  • 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 as they both listen on port 53 UDP. See DNSBestPractices
  • Does not, and author's code will not, support - DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6
  • 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 (Knowles's report)
  • No good conversion tools from Bind (might be now, needs checking)
  • Slow. Anecdotal reports of high speed unproven. Testing by the author of this paper shows low performance (Knowle's report)

Pros: 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:

  • Single data file manages all zones. This makes management of zones very easy.
  • Zone file format is claimed to be more streamlined than bind.
  • Adheres to 'The Unix Way' - lots of small processes doing small tasks, rather than a large monolithic approach
  • Use of cdb format data file allows use of quicker, push mechanism for zone transfer - rsync over ssh.
  • Written with security in mind from the outset.
  • Very easy split-horizon dns setup for dnscache
  • Written to pre ANSI-C specifications and therefore compiles on most if not any Unix platform.
  • cdb data file is non-platform specific and thus the binary cdb file can be copied across to any OS platform and be used without any problems. (cdb, like djbdns, is non-Free software, meaning that free linux distributions cannot package it since they are not allowed to modify it.)

Comparison:

  • As a caching dns, bind is inefficient compared to dnscache and thus drops query requests far more than dnscache although bind maintains by default a 1000 entry deep query queue whereas dnscache only has 200 defined. However, if not in need of extreme performance, bind will not send out duplicate queries and is thus less likely to be treated as abusive whereas dnscache does not keep track of queries, it just sends them out as they come if answers are not cached. dnscache suffers from not being multi-threaded and so will only utilize one cpu, and fully if necessary, even if there are more cpus available...but even so, in performance tests involving thousands of queries per second, only it can handle high loads whereas bind will drop queries.
  • Bind does not go through the thorough checking dnscache does and so it will retrieve records faster by using glue records. eg: Akamai has some really obnoxious dns entries for its worldwide load-balancing service which is used by yahoo.com. Try a dig www.yahoo.com @bindip and a dig www.yahoo.com @dnscacheip. dnscache takes a while before you get an answer.
  • A lot of people cite the file format as big feature. That is, they find tinydns's file format much easier to understand than BIND's. One person likened BIND's file format to a 'programming language' - I wonder if they were confusing it with sendmail?

Readers notes

(dnscache) I don't know about the author, 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 part about bind being multiple times faster is complete nonsense to me 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. -- ChristopherChan

The report published at the top of this page was performed several years ago - it's possible some things have changed. DJB has a page refuting many of Brad Knowles's claims, entitled Brad Knowles's Slander. I've not taken the time to go over it thouroughly, nor have I investigated relative merits of the two DNS servers further than reading Brad's original paper. DJB seems to contradict some of Brad's points simply by rejecting the wording, without bothering to answer the meaning. Brad also referred to works published by DJB himself regarding TinyDNS performance, which seems fair enough to cite. The fact that performance has improved since then bears little relevance on the state of things at the time. I encourage interested readers to go over both documents and make up their own mind. I'll keep using BIND because it's what I know, performance is perfectly fine for what I need it for, and any security concerns are very outdated. -- DanielLawson

** Er, why do you want both an authoritative and caching server on the same ip anyway? --ChristopherChan ** This is a good point. ISC say not to; lots of places say not to. This doesn't stop people doing it, however, and it causes problems. It causes more problems than doing this with BIND. I'm not saying the software should hand hold the administrator in to not doing silly things, but this behaviour is still out there. --DanielLawson ** And not being able to do this obviously bad behaviour makes it a Con? Am I missing something here? You say it causes more problems. How, may I ask, does it cause more problems when you cannot even get yourself into that situation anyway? Only BIND allows you to run both a dns cache and an authoritative server on the same ip. Don't you mean you only get problems if you run this kind of config with BIND? --ChristopherChan ** I've seen at least one site with tinydns and dnscache set up in a broken manner. Ok, strictly speaking it's not using the same IP for each, however the end result is worse - DNS queries often come back with the authoritive nameserver being localhost. ** That is hardly a con because the person who set it up sets it up in this. Nowhere will you find it documented as such. The person obviously has enough understanding to be able to make it work. This is also a split-horizon setup which can be very useful and I make a lot of use of it except that I run my internal tinydns on its own box since I have multiple dnscaches instead of one and they all need to refer to the tinydns hosted records. Be reasonable. Not being able to run the cache and authoritative on the same ip is not a con but a pro. Separtion of dnscache and authoritative is the recommended way of running things. --ChristopherChan

I should point out again that the original bullet points listed at the top of this page were all pulled from Knowles's report. I've edited a few points where they were proven to be no longer correct. Very little of the original content is authored by me, and the recent edits are merely conversation. If you feel something in the bullet points is incorrect then you can feel free to correct it. We've had some really whacko updates before, yours seem to be on the level. If they're wrong, inflammatory or offensive, they'll get removed. I feel there are enough situations where it's "ok" to run an authoritative NS and a cache on the same IP that this particular point is worth leaving in, although the point could be expanded to point out why it's a bad thing for "real nameservers". Consider any SMB, SOHO, or student flat network - they might have need for both. Maybe they can get around it, maybe it's not worth the hassle. --DanielLawson