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.

These points were originally pulled 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. Since then DJB has put up a page refuting many of Brad Knowles's claims, entitled Brad Knowles's Slander. Sifting through the facts is hard, and there is no real 'definitive' answer as to which is the best DNS server - that's entirely dependant on the site.

(Visitor's note: It is unfortunate that many of the statements presented below as cons for djbdns are provably incorrect. I run dnscache and tinydns on the same server and through the same IP at home, for example. dnscache is blindingly fast once an address has been resolved from the Internet. And, as far as I know, neither app violates the RFCs. I really think the writer should have taken more care to provide an objective comparison. I realise this article dates from 2005 but Dan Bernstein highlighted many years ago exploitable holes in BIND which have suddenly (in 2008) become big news but which do not arise with his DNS apps. Saying at the beginning that this comparison "...won't be fair or unbiased" is a total cop-out and should be taken by readers to mean that they should discount the analysis completely since it explicitly makes no attempt at objectivity. It is simply a repetition of known untruths to knock an excellent product. I don't know anything about wlug, but I don't think it does you any favours as an organisation.)

Bind 8


  • 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


  • 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 (possibly anecdotal)

Bind 9


  • 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


  • Unusably slow with only several hundred recursive clients (possibly anecdotal)
  • Seems to run into problems maintaining cache database after a while and over 250mb cached data (possibly 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?)

The author of the original 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.)


  • 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)

Comparison of caching resolvers:

  • BIND is claimed to be less efficient than dnscache as a caching DNS server, and may drop more requests as a default. BIND's default cache is limited by the TTL of its entries however, whereas dnscache only has 1MB by default.
  • BIND will not send out duplicate queries, and is less likely to be treated as an abusive DNS server, whereas dnscache does not limit outgoing queries if the answer hasn't been cached yet.
  • dnscache is not multithreaded, so will not make use of more than one CPU. BIND is multithreaded, but this seems to be problematic in some cases.
  • In terms of performance, dnscache seems to beat BIND at high loads.
  • BIND will return results quicker in some cases, due to less extensive checking than dnscache. For example, Akamai has some really obnoxious dns entries for its worldwide load-balancing service which is used by Try a dig @bindip and a dig @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?