Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Review: DNScache 1.0

By MikeBat in News
Fri Jun 30, 2000 at 10:54:41 PM EST
Tags: Software (all tags)

Dan Bernstein, perhaps better known as the author of the Qmail SMTP server, has developed a high quality alternative to BIND. DNScache 1.0 was released earlier this year, and in keeping with the philosophy behind Qmail's design as an alternative to Sendmail, it was designed primarily to overcome the security and performance weaknesses of existing DNS software (read: BIND).

DNScache is perhaps an unfortunate name for the package, because caching only begins to describe what it does.

Dan's bundle of DNS utils and servers is called DNScache, but that only begins to describe it. DNScache consists of the following components, each of which operate independently or in conjunction with each other to provide a complete suite of DNS services that is capable of replacing BIND in most installations.

  1. dnscache - A client resolver daemon, it listens for UDP and TCP queries, recurses on behalf of clients, and caches answers based on simple rules that are designed to thwart cache poisoning attacks.
  2. tinydns - An authoritative DNS server, it listens for UDP queries, and answers with zone data read directly from a fast hash database, and is immune from cache poisoning because it doesn't have one.
  3. axfrdns - The zone transfer server, it reads data from the tinydns database to satisfy zone transfer requests in order to provide interoperability with BIND. It also answers client queries over TCP from the tinydns database.
  4. axfr-get - The zone transfer client, again for BIND interoperability.
  5. walldns - A specialized in-addr.arpa DNS server, it provides consistent forward and reverse resolution for your netblock without revealing any hostnames and requires no zone data.
  6. pickdns - A load-balancing DNS server that can answer with different records depending on the client source address.
  7. rbldns - A specialized DNS server suitable for serving lists of IP addresses, RBL-style.

All servers run chrooted, as a non-privileged userid. They are managed by another package called daemontools, which supervises the daemons, and allows the admin to send signals to managed processes. Daemontools also manages the logs for the programs it supervises. To support DNS over TCP or zone transfers, you'll also need to get ucspi-tcp.

This review will focus on dnscache and tinydns, the tools most likely to be useful to most installations.


The caching client resolver component implements a number of design features that make it practically immune to attack. For one, its responses are given with a TTL of zero, to make it difficult for hostile clients to discover when the TTL expires for a particular record, which in turn makes it difficult to mount some poisoning attacks that can affect BIND. Because of this, dnscache is only suitable for listing in a client's resolv.conf or equivalent. It should never be listed as authoritative for a domain for this reason, and also because it never sets the authoritative flag in its responses. This also means that it cannot daisy-chain to another dnscache, as is often done with BIND in split-DNS configurations. But no matter, dnscache has other features that make it firewall-friendly. It reads a configuration file at startup which is the equivalent of the BIND cache or hints file, and uses those servers as the roots. Unlike BIND, it believes the sysadmin when he tells it who the roots are. BIND queries the servers listed in its hints file, and uses their answers to discover the roots. DNScache can also be told to ignore the roots for particular domains, and query the designated servers directly. This allows it to service queries for public domains and private domains without a messy split-DNS setup.

Its credibility rules are the heart of its poison avoidance strategy. DNScache will not return or cache a response while recursing to resolve a domain name unless it got the answer from the roots, the authorities for the second-level domain, or the authority for the domain itself. It rigorously refuses to believe any answer that does not descend from a chain of delegations that can be traced to the roots (or from an admin override). Out-of-zone glue is discarded. Dr. Bernstein would like to see domain policies changed so that all servers listed in the roots belong to the zone they are authoritative for. This would eliminate the possibility of cache poisoning, and simplify the administration of the registries. But it would also require that the registries allow a single host (IP address) to have more than one name.

Finally, DNScache uses a configurable cache size, and will not exceed this limit. Records are normally expired according to the TTL given by the authority for the domain. But if the cache size would exceed the admin's limit, records are discarded in order of least-recently-used to make room for new ones. The default size of 1Mb is probably too small for sites larger than a home DSL or cable modem user. I'm using a cache size of 30Mb to service 2000 employees and the production environment at CitySearch and Ticketmaster Online. Our two DNS servers are refurbished Sun Ultra200E workstations with only 128Mb memory installed. Load never exceeds 0.5, even at the peak. Each DNS server runs two instances of DNScache that are each listening on their own network segment.

Be aware that DNScache can be more stressful on a NAT device than BIND. It uses a random source port for each query, whereas BIND picks one source port at startup and uses that for all queries. This means that each query made by DNScache will be seen by a NAT device as a new session, even if it is to a nameserver that was just queried a moment ago. The sessions can mount up and may overrun the resources of your NAT device. I am moving my NAT system to the near side of our WAN link so that I can run DNScache on the NAT system itself, and avoid creating 30,000 NAT sessions on our IP-filter NAT box when our weblog analyzer makes its daily romp through the log files.


This is the authoritative DNS server component. It reads zone data directly from a fast hash database of Bernstein's design called cdb or constant database. This database is compiled from a text source file with a format that is easy for programs (awk, sed, perl) to edit, and reasonably easy for humans to read and edit. It's compact, and after a short period of use, I prefer it to BIND's zone file format. Here's a sample zone file:


The 'Z' record signifies SOA. This is an optional record. If it is absent, tinydns will create one for you. It uses the timestamp of the data.cdb database as the serial number. Here, I have overridden the server and contact fields. The serial, refresh, retry, maximum and other fields are created automatically (and the defaults are very reasonable, so I don't worry about them).

The '.' records signify the NS, and also inform tinydns to set the authoritative bit for NXDOMAIN responses for names underneath ticketmaster.com that do not exist. In this example, I have also set the TTL to 5 days, though if this is omitted, tinydns uses its default of 3 days for NS records. This is in contrast to the '&' record, which in this example is a delegation to our Alteon load-balancing gear (with a five minute TTL). Tinydns will return the delegation, will not set the authoritative flag, and will not return NXDOMAIN for names under www.ticketmaster.com that do not exist.

There's a neat feature here that is obscured in my example. All you need to setup your glue and your SOA is the '.' records. When the authority records are this:


Tinydns automatically creates SOA, NS and A records corresponding to this in BIND zone file format:
$ORIGIN com.
domain  IN      SOA     a.ns.domain.com. hostmaster.domain.com.
        ( 962318946 16384 2048 1048576 2560 )
$ORIGIN domain.com.
        IN      NS      a.ns.domain.com.
        IN      NS      b.ns.domain.com.
$ORIGIN ns.domain.com.
a       IN      A
b       IN      A

Likewise, the '@' record, signifying the MX for the domain, can setup in one line all the records associated with an MX host:

This is equivalent to these BIND zone file records:
$ORIGIN com.
domain  IN      MX      10 a.mx.domain.com.
        IN      MX      20 b.mx.domain.com.
$ORIGIN mx.domain.com.
a       IN      A
b       IN      A

Note that in the ticketmaster.com example, I use out-of-zone MX and NS, so I leave the IP address field blank, and just specify the fully qualified name of the NS and MX hosts in the third field. I also specify priorities for the MX in the fourth field. If this is omitted, tinydns supplies a priority of zero.

You'll notice that I specified authority for two in-addr.arpa domains. This enables the '=' record to create both A records and corresponding PTR records with just one entry. The '+' record signifies only the A record, while the '^' record signifies a PTR.

There's another nifty feature that I want to touch on, which I have never seen in another DNS server. You can specify a time in the future when a record is to expire and be replaced by a new one. The timestamp is specified in external tai64n format.

In this example, the domain www.heaven.af.mil will have the address until 4000000038af1379 (2000-02-19 22:04:31 UTC), at which point it becomes As that date approaches, the TTL of the expiring record is adjusted dynamically so that it will expire from caches at or shortly after the date of the timestamp. DNScache includes utilities to convert tai64n to standard ISO format (useful for tailing dnscache log files, which also use the tai64n time format).

Performance and Operation

DNScache is easy to build. The build process is similar to that of Qmail. You edit conf-home, conf-cc and conf-ld, and run make. The code is clean and well-formatted (I'm no C wizard, so take that assessment with a grain of salt :). It compiles cleanly with no errors and few or no warnings on Linux, BSD, Solaris and Irix (in my experience), using either gcc or the vendor compiler. Any OS reasonably compliant with POSIX, and any compiler reasonably compliant with ANSI-C ought to suffice.

DNScache and tinydns are models of simplicity and economy. Even during popular ticket sales at ticketmaster.com, tinydns utilizes less than one percent of CPU time, and uses just 1688Kb of memory on Solaris Sparc. Hundreds of thousands of visitors try all at once to login and buy tickets during popular on-sales (think Nsync or Ricky Martin). Its memory footprint remains small (hence the tiny in tinydns) regardless of how many domains it services. On average, tinydns services about 1.2 million DNS queries per day for all the domains I have converted to tinydns, and none of the nameservers break a sweat. It has been completely reliable and no trouble at all to operate. In addition, since all zone data are contained within a single hash database file, it is a simple matter to do away with zone transfers from the slave nameservers. I simply use rsync over SSH to send data.cdb to the slaves. Updates propagate instantly. One DNScache user has contributed a perl script to send NOTIFY messages to slaves that happen to run BIND. See the DNScache FAQ for more information and user-contributed patches, including IPv6 support.

Aside from the problem with excessive NAT sessions that I mentioned earlier, dnscache has performed like a champ. The mail relay for citysearch.com has been resolving queries through dnscache for three months now, and there have been no problems attributable to dnscache. This mail server relays over 35,000 newsletters, announcements and ordinary user-to-user messages each day. Granted, this volume doesn't approach that of, say Hotmail, but it's significant nonetheless, and shows that the performance of dnscache is more than adequate for most installations.

In conclusion, I would say that DNScache is the first full-featured, non-proprietary replacement for BIND I have encountered that addresses all the weaknesses of the program many of us love to hate. Qmail showed that not all mail problems need to be solved by consulting the "Bat Book". Likewise, DNScache shows that when you're in a BIND, you have other options than what are shown in the "Cricket Book". It's a good thing that there are modern replacements for critical services, with design goals informed by past experience with the old standbys. DNScache easily deserves its place next to Qmail as one of those programs.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Dan Bernstein
o Qmail
o DNScache 1.0
o Sendmail
o daemontool s
o ucspi-tcp
o cdb
o external tai64n format
o DNScache FAQ
o "Bat Book"
o "Cricket Book"
o Also by MikeBat

Display: Sort:
Review: DNScache 1.0 | 26 comments (26 topical, editorial, 0 hidden)
License ? (5.00 / 1) (#1)
by Anonymous Hero on Fri Jun 30, 2000 at 09:28:50 PM EST

The one question I had when I finished reading was that of the license of the software... which I will now go find out :) Ian

Re: License ? (4.50 / 2) (#4)
by dmarti on Sat Jul 01, 2000 at 02:36:47 AM EST

It's under the non-free "Bernstein license" (like qmail) which means it can't be modified -- you can't distribute a package that puts files in different places from where they live on the author's system. So it won't make it into the Linux distributions.

[ Parent ]
Re: License ? (1.00 / 1) (#13)
by cicero on Sat Jul 01, 2000 at 11:59:32 PM EST

Sorry, that's just not true. Qmail made it into linux distro's. try
# apt-get install qmail-src
from your local debian box, or
# rpmfind qmail
from your local redhat box. (don't know about others, this is all I've installed qmail on.) cicero

I am sorry Cisco, for Microsoft has found a new RPC flaw - tonight your e0 shall be stretched wide like goatse.
[ Parent ]
Re: License ? (none / 0) (#20)
by Anonymous Hero on Sun Jul 02, 2000 at 03:11:19 PM EST

qmail-src is distributed in the non-free section (non-free/mail).

[ Parent ]
Free to use, not free to fork (4.50 / 2) (#5)
by Anonymous Hero on Sat Jul 01, 2000 at 03:28:14 AM EST

One can read Dan Bernstein's views on redistribution here. In essense, one is free to download, compile and use the package as one wants. Dan explicitly forbids forking the package in any way. That means you can create a binary package, but it must install and work exactly as if the package had been compiled then installed on the system.

As always, Dan has no power to stop distribution of dnscache patches, just patched versions of dnscache.

John White

[ Parent ]

Wow. (3.00 / 5) (#2)
by Wolfkin on Sat Jul 01, 2000 at 12:29:32 AM EST

THIS is the way stories should be. :)


Re: Wow. (1.00 / 1) (#7)
by Anonymous Hero on Sat Jul 01, 2000 at 04:50:29 AM EST


[ Parent ]
Re: Wow. (none / 0) (#25)
by jhillyerd on Mon Jul 03, 2000 at 02:36:16 PM EST

Ditto. Very well written!

[ Parent ]
Nonstandard DNS records (5.00 / 1) (#3)
by mind21_98 on Sat Jul 01, 2000 at 12:36:32 AM EST

According to the standards for DNS, the Bind way of storing DNS information (domain IN A for ex.) seems to be the standard. Does this mean dnscache is violating the current DNS standard? I don't think it violates the DNS standard in respect to how it sends and receives messages.

mind21_98 - http://www.translator.cx/
"Ask not if the article is utter BS, but what BS can be exposed in said article."

Re: Nonstandard DNS records (4.00 / 1) (#6)
by Anonymous Hero on Sat Jul 01, 2000 at 03:49:38 AM EST

rfc 1033, 1034, and 1035 seem to be merely documenting the way that bind worked then, and still works now. Fer sure bind's zone files aren't the representation what goes over the wire.


[ Parent ]
Re: Nonstandard DNS records (5.00 / 1) (#22)
by Anonymous Hero on Sun Jul 02, 2000 at 05:48:09 PM EST

From RFC 1033:

"Zone files are standardized ..."

Many consider it to have been a mistake for PVM to put the zone file format in the DNS protocol specification, however, he did and it is part of the standard. But standards conformance never seemed to really concern djb (except when convenient).

[ Parent ]

Re: Nonstandard DNS records (none / 0) (#26)
by moth on Wed Jul 05, 2000 at 11:48:08 AM EST

For internet standards, the golden rule is: be conservative in what you send and liberal in what you accept...

...seems to me that the RFCs don't really talk about sending or accepting anything in this file format. So how can dnscache be violating the standard?

However: the root zone files are in this format, and it is reasonable to want to use them with tinydns (if you want your own local root dns server). And, for this, a short perl script is enough to convert the file to tinydns-data format.

Also, for what it's worth, dnscache supports files stored in any of bind's format -- using bind to parse the files, and AXFR to load them into dnscache. [And, since this application doesn't require bind being able to communicate with the outside world, it needn't violate dnscache's security guarantees.]

[ Parent ]

BIND9? (4.50 / 2) (#8)
by mihalis on Sat Jul 01, 2000 at 11:53:42 AM EST

So how does this compare to BIND 9"? I read the "Cricket book" earlier this year and thought myself pretty up-to-date (3d edition - covers BIND8!)

Then almost immediately I saw at the sendmail.net site that a complete rewrite from scratch was just about finished, and Paul Vixie called it a "thing of beauty" - see this article

Not running any nameservers myself, I'm not in a position to comment authoritively, but I wonder if MikeBat is giving the latest BIND a fair crack of the whip in this review or whether DNSCache is only (apparently) better than the BIND version he's used to.
-- Chris Morgan <see em at mihalis dot net>

Re: BIND9? (none / 0) (#14)
by KindBud on Sun Jul 02, 2000 at 12:13:09 AM EST

I haven't seen BIND9 yet, and I didn't really want to focus on BIND-bashing when I wrote the piece. DNScache stands on its own merits. There are plenty of reasons to choose it besides "it's not BIND".

just roll a fatty

[ Parent ]
Re: BIND9? (none / 0) (#15)
by KindBud on Sun Jul 02, 2000 at 12:14:14 AM EST

Oops. Guess my anonymous login isn't so anonymous anymore. ;)

just roll a fatty

[ Parent ]
Re: BIND9? (none / 0) (#18)
by mihalis on Sun Jul 02, 2000 at 10:26:54 AM EST

That's fair enough, but "it was designed primarily to overcome the security and performance weaknesses of existing DNS software (read: BIND). " could have been said by the authors of BIND9 too.

I think my feelings on this issue are somewhat related to my feelings on sendmail. I know that qmail is great, lots of experts use it, however some of the qmail advocacy harks back to the bad old days of sendmail when admins really did have to write their own config file. I've never had to worry about sendmail for my limited need in four years adminning slackware boxes - a quick bit of reading, run the input file through m4 and restart and whoo-hoo it "just works".

. Although your piece only claims to be a review of DNSCache, and although I think the main chunk of of your piece is truly excellent, and fascinating, and the kind of stuff I come to this place for, it seems to be bracketed at beginning and end by slightly unfair digs at BIND given that BIND8 is reaching end of life and BIND9 is too new to have proven itself.

But then again it is a Sunday morning and I haven't had my coffee yet ;^)

Chris Morgan
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

Re: BIND9? (none / 0) (#19)
by Anonymous Hiro on Sun Jul 02, 2000 at 02:56:37 PM EST

I think my feelings on this issue are somewhat related to my feelings on sendmail. I know that qmail is great, lots of experts use it, however some of the qmail advocacy harks back to the bad old days of sendmail when admins really did have to write their own config file. I've never had to worry about sendmail for my

The difference between sendmail and qmail is that you don't have to keep security patching qmail every month or so.

And it looks like BIND is a bit too much like sendmail in the bad days. Look at the recent remote root problems.

As for BIND9 specifically, it looks like it's just Bind 8 with more features. The basic architecture looks to be the same. So it doesn't give me more confidence with regards to security issues.

Anonymous Hiro.

[ Parent ]

Re: BIND9? (none / 0) (#21)
by Anonymous Hero on Sun Jul 02, 2000 at 05:34:59 PM EST

As for BIND9 specifically, it looks like it's just Bind 8 with more features.

Sounds like you haven't even bothered to look at BIND9 before commenting.

BIND9 is a complete redesign and rewrite. There is no code shared between the two. BIND9 had an architect, BIND8 evolved over 15 years. BIND9 uses "programming by contract", BIND8 had little to no software engineering. Etc.

Oh yeah, and since BIND9 is under a BSD-like copyright, you can fork it or put it where ever you like in distributions. Can't do that with dnscache -- you'd violate Bernstein's license (he knows better than you, see...)

[ Parent ]

Re: BIND9? (none / 0) (#23)
by Anonymous Hero on Sun Jul 02, 2000 at 08:44:43 PM EST

BIND9 is a complete redesign and rewrite.

Well, that's great, but guess who wrote it. The same ninkumpoops who messed up DNS to begin with. Lots of the people on namedroppers@whereveritisnow.com (probably psg, since internic couldn't host the ignoramous anymore) contributed to BIND9 as well. I've been following their blundering on that list for years. Read through some archives, see who you trust.

Sure, it'd be nice if they just had a clean slate to start clean on, which is what people are pushing for. Sorry, that's not how I work. They had their chance on my servers, they messed up. Go tell someone else about your "complete rewrite."

[ Parent ]
I did look. (none / 0) (#24)
by Anonymous Hiro on Sun Jul 02, 2000 at 11:24:36 PM EST

I did look at it.

So they are renovating the insides, but it seems as if the building is going to look the same, and it's being rebuilt by the same people.

How well they renovate/rebuild remains to be seen. Major rewrites are usually either negative or unrelated with respect to actual security, just look at Linux's IP stack rewrite for 2.2.x.

Whereas dnscache is definitely a new architecture, which looks much easier to be made secure and robust. And it's been written by Dan Bernstein.

Whatever you wish to say about Dan, qmail has not needed any bug patches since May 1998, nor has anyone claimed the USD1000 prize.

BIND is more feature driven, and definitely less security driven - looking at their plans page, it shows. Given that, from a security standpoint, I'd rather someone else give them the benefit of doubt :).

I'd use BIND if I really need certain features, but not where security is important. Well it's just too bad if they've developed a negative brand recognition with regards to security- they've had so many versions and revisions to fix that with no luck, and doing DNS securely is actually simpler compared to doing mail, www or ftp securely. Embarassing.

Anonymous Hiro

[ Parent ]

Seconded (none / 0) (#9)
by agl on Sat Jul 01, 2000 at 12:14:02 PM EST

I've dumped BIND and switched to DNSCache and been very happy. Along with daemontools (by same author) it works perfectly and is much more simple than BIND.

The only problem I can see is that while BIND always gets UDP replies on 53 - DNSCache expects them on all number of different ports - so you have to open up the firewall somewhat.

Then again I'm sure I could patch the code around this - the author is right when he says it's well organised

Another alternative (4.00 / 1) (#10)
by yelvington on Sat Jul 01, 2000 at 01:34:51 PM EST

(Excellent piece, by the way.)

Many of us who run home networks might benefit from setting up DNS servers. Rather than devote the necessary resources to BIND, I have been happily running DNRD, the DNS Relay Daemon. Obviously it's aimed at a different set of users than the full-featured DNSCache setup. There's only one program, and it's only 38K.


This lets my internal machines point to my Linux box, and it seems to have lessened the Netscape "DNS Helper" problem under Linux.

Re: Another alternative (none / 0) (#12)
by Anonymous Hero on Sat Jul 01, 2000 at 11:16:02 PM EST

Thanks! I spent a while two weeks ago trying to figure out how to get BIND to do something like that!

[ Parent ]
Another alternative (none / 0) (#11)
by yelvington on Sat Jul 01, 2000 at 01:34:58 PM EST

(Excellent piece, by the way.)

Many of us who run home networks might benefit from setting up DNS servers. Rather than devote the necessary resources to BIND, I have been happily running DNRD, the DNS Relay Daemon. Obviously it's aimed at a different set of users than the full-featured DNSCache setup. There's only one program, and it's only 38K.


This lets my internal machines point to my Linux box, and it seems to have lessened the Netscape "DNS Helper" problem under Linux.

This is great! (none / 0) (#16)
by Ranger Rick on Sun Jul 02, 2000 at 12:30:57 AM EST

I saw this article here earlier today and went about setting it up. There are a lot of dependencies (instead of just compiling BIND and forging ahead), but all in all, it was fairly easy to install (I like svc, it's quite spiffy).

I've now replaced my big hulking BIND server (overkill for caching-only) with a nice small DNSCache one.

Hooray! :)


expiry times and TAI64N (none / 0) (#17)
by Anonymous Hero on Sun Jul 02, 2000 at 06:21:10 AM EST

There is also a small tool to convert ISO times to external TAI64N format. You may find it at www.dnscache.de


Review: DNScache 1.0 | 26 comments (26 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!