BIND 9.1.2 and TinyDNS???

Mon Jun 11 15:11:27 UTC 2001

I guess a good question is, if you are already running BIND, what are their
reasons for switching?

You'd think the new implementation should have to fight for reasons to get
in the door, and not the current implementation fighting for its job.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Brad Knowles" <brad.knowles at skynet.be>
To: "Johnny Damtoft" <JOD at sonofon.dk>; "ISC DNS (E-mail)"
<bind-users at isc.org>
Sent: Monday, June 11, 2001 9:42 AM
Subject: Re: BIND 9.1.2 and TinyDNS???

>
> 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,$_)}'