Differences between version 26 and predecessor to the previous major change of BindVsTinyDNS.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 26 | Last edited on Tuesday, June 21, 2005 8:42:33 am | by JohnMcPherson | Revert |
| Older page: | version 25 | Last edited on Tuesday, June 21, 2005 3:16:15 am | by ChristopherChan | Revert |
@@ -55,8 +55,11 @@
* 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:
@@ -66,9 +69,9 @@
* 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 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.
