Differences between version 27 and predecessor to the previous major change of BindVsTinyDNS.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 27 | Last edited on Saturday, July 23, 2005 12:04:44 pm | by DanielLawson | Revert |
| Older page: | version 26 | Last edited on Tuesday, June 21, 2005 8:42:33 am | by JohnMcPherson | Revert |
@@ -1,28 +1,28 @@
[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.
-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 :)
+These points were originally pulled from Brad Knowle's paper on [Name Server Comparison|http://www.shub-internet.org/brad/papers/dnscomparison/DNSComp.pdf.bz2].
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|http://cr
.yp.to/djbdns/knowles.html]. 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.
-I'm pulling these points (for now) from Brad Knowle's paper on [Name Server Comparison|http://www.shub-internet.org/brad/papers/dnscomparison/DNSComp.pdf.bz2]. This paper was focussed on performance of an authoritative or caching nameserver, but discusses the differences in the servers as well.
-
-:
-Pro
:
+! Bind 8
+Pros
:
* 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
+* uses way too much cpu for subsequent SERVFAILs (possibly anecdotal)
-! Bind 9:
+! Bind 9
Pros:
* Full recursive/caching and authoritative name server implementation
* Recursive/caching and authoritative services can share IP addresses
* Ground-up rewrite, secure
@@ -38,14 +38,26 @@
* 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.
+* 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:
+
+Pros:
+* 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.)
Cons:
* Violates RFCs
* Doesn't provide referrals by default
@@ -59,41 +71,13 @@
* 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
of caching resolvers:
-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.
+* 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
1000 entries however,
whereas dnscache only has 200 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 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|http://cr.yp.to/djbdns/knowles.html]. 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
