BIND 9.1.2 and TinyDNS???

Brad Knowles brad.knowles at skynet.be
Mon Jun 11 13:42:06 UTC 2001


At 1:08 PM +0200 6/11/01, Johnny Damtoft wrote:

>  Here we are running Bind 9.1.2, and now someone wants to make a TinyDNS
>  server and shutdown bind.
>
>  Im not happy about that disission, but what im looking for, is witch server
>  is the best? and why?
>
>  Ill like to know something about the good sides and the bad sides of both
>  dns servers.

	There are a number of problems with TinyDNS.

	For one, it does not hand out referrals to questions that are 
asked of zones it does not control.  If you were to query an 
authoritative-only nameserver running BIND about a zone it is not 
authoritative for, it will give you a list of nameservers (usually 
the root nameservers) that are more likely to be able to help you. 
TinyDNS assumes that anyone who asks you a question about a zone you 
are not authoritative for is mis-configured and simply ignores them. 
I believe that this is a violation of the RFCs, at least in spirit if 
not in the letter.

	Secondly, TinyDNS is an authoritative-only nameserver.  It is not 
capable of caching.  If you want recursion and caching in addition to 
authoritatively serving zones, that requires a separate program, 
dnscache.  While I recommend dedicating separate machines for the 
authoritative-only and recursive caching-only services, many sites do 
not have this option.  At the very least, TinyDNS and dsncache make 
it difficult to run both services on the same machine.  Contrariwise, 
if you do want to split these services onto separate machines, you 
can just set up an authoritative-only configuration on one machine, 
and a recursive/caching-only configuration on another.

	Thirdly, many sites want to have separate internal versions and 
external versions of their DNS data.  Since you can't mix these two 
services in the same program, you end up having to set up separate 
external and internal TinyDNS servers, and then use forwarding on the 
internal dnscache servers for the zones served by the internal 
TinyDNS servers.  But forwarding can create very complex 
configurations that are more easily mis-configured, more easily 
accidentally taken out of service, are more "brittle", and much less 
scalable.  See pages 333-335 in Chapter 11 of _DNS and BIND_, 4th 
edition (written by Paul Albitz and Cricket Liu, published by 
O'Reilly & Assoc.).  This could be much, much more easily done with 
something like the "view" mechanism that is included with BIND 9.

	Fourth, there is no support in TinyDNS or dnscache for the DNSSEC 
extensions, whereby you can create cryptographically secure zones, 
and with BIND 9 acting as a DNSSEC-aware resolver, you can 
automatically benefit from these features for all DNS clients, even 
if they themselves are not DNSSEC-aware.  DNSSEC is not yet all that 
important, but it is a key part of IPSEC, certain parts of IPv6, and 
many VPN solutions (because they're based on IPSEC, such as PGPnet). 
Indeed, there are plenty of other aspects of the DNS RFCs which I 
believe that TinyDNS does not implement at all, or does not implement 
correctly.

	Fifth, the code has had much less time to prove itself, and IMO 
is much less stable.  There are estimates that between 70% and 95% of 
all Internet zones are served by one variant or another of BIND, and 
while a lot of these are older and much less secure versions of BIND, 
there are still more sites out there running BIND 9 than there are 
sites running TinyDNS.  Heck, I'd be willing to bet that there are 
probably more sites out there running the new alpha version of BIND 
9.2 than there are running TinyDNS.  No matter what you think of 
Dan's $500 security hole guarantee, this doesn't help you one damn 
bit if a security hole is actually discovered, and your entire 
network is compromised and you have to spend many hours and thousands 
or tens of thousands of dollars worth of person-hours to recover. 
Having more sites run your code means that you have more people 
helping to detect and report bugs, which means that the bugs get 
found faster and the code is provably more stable -- BIND has this, 
TinyDNS does not.

	Sixth, there is relatively little documentation or support for 
TinyDNS.  Your support network is limited to Dan and his fanatics. 
Contrariwise, with BIND, not only do you have at least three books on 
BIND specifically (see <http://www.dns.net/dnsrd/books.html>), 
including the seminal work _DNS and BIND_ by Paul Albitz and Cricket 
Liu (published by O'Reilly & Assoc.), which is now in its fourth 
edition.  There is also the book _Sams Teach Yourself Dns/Bind in 24 
Hours_ by Edward Branley and Peter Jeffe (Paperback - 400 pages 
(February 15, 2001) ISBN: 0672317176), as well as _Internet 
Directories: How to Build and Manage Applications for LDAP, DNS, and 
Other Directories_ by Bruce Greenblatt (Hardcover - 290 pages 1st 
edition (January 15, 2000), published by Prentice Hall PTR; ISBN: 
0139744525).  You also have this mailing list/newsgroup, plus you can 
buy commercial-grade support through the Internet Software 
Consortium, including the possibility of full 24/7 telephone support, 
as well as on-site consulting, training, etc... (see 
<http://www.isc.org/services/support/>).  Of course, when it comes to 
training, the ISC is by no means the only group offering training in 
BIND -- classes are also available at most USENIX, SAGE, SANS, and 
SANE conferences around the world, and there are third-party 
companies offering their own training and consulting.

	Seventh, there are some performance problems with TinyDNS.  Dan 
claims that it is faster than BIND, but recent benchmarks that I've 
seen under development through this mailing list have indicated that 
it cannot keep up with BIND 9.1.2 on a single-processor server, and 
on a multi-processor/multi-threading server I am quite confident that 
it would fall way behind.  Early testing with BIND 9.2 indicates that 
it eliminates some critical bottlenecks in BIND 9.1.2, which means it 
should be even faster.  Bill Manning has also reported some 
performance problems they've seen with TinyDNS.


	If all or most these problems can ever be resolved, and TinyDNS 
is put into permanent use on one or more root nameservers (and/or 
gTLD nameservers), then I might be willing to take another look at 
it.  Until then, I wouldn't bother.

	If you really must have an alternative to BIND, there are 
commercial programs from a variety of companies, or there is the 
freely available DENTS package.  I don't know that any of these can 
really compare particularly well against BIND with regards to all 
seven of the above issues, but they certainly couldn't do much worse, 
and some of them are probably at least worth considering.

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'


More information about the bind-users mailing list