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