Tinydns: Kiss Your BIND Good-bye
If you're feeling bedeviled by BIND and nagged by named, Tinydns is a scalable and secure replacement for everything from home user DNS cacheing to large-scale enterprise networks.
DNS admins rejoice, for thy long years of torment are over. No more shall BIND bewitch and betray thee, for there is a new kid on the block: Tinydns.
No discussion of Tinydns is complete without mention of its author, D. J. Bernstein. Professor Bernstein is a very smart mathematician and scientist. He has written and given away many top-quality programs, such as qmail, daemontools, ezmlm, and djbdns. He offers cash rewards to anyone who can find security holes. He is suing the US Government. Professor Bernstein is not known for inspiring love and affection, to the point that many people refuse to use his software.
This is a mistake. BIND has been maintained over the years by a number of different people, many of whom are nice, lovable persons. No matter how lovable these hardworking, admirable persons are, BIND is a mess.
Tinydns does things very differently from BIND: small, secure, easy to configure, and scalable, all the way from home user using dnscache to speed up Web browsing, to giant mega-sites handling hundreds of queries per second with tinydns. No more named handling both authoritative name services and caching services, whether you need all that baggage or not. Every chore is handed off to small, specialized components that are installed and used only as needed.
Some other interesting components of djbdns:
- rbldns: server for managing RBLs (realtime blackhole lists)
- walldns: untruthful server that creates fake answers to IP address lookup requests. Used to protect your internal network
- axfrdns: handles TCP queries and zone transfers. Prof. Bernstein does not think much of DNS-over-TCP, he says it is slower than DNS-over-UDP, and more vulnerable to denial-of-service attacks. Here it is anyway, for those who want it.
I love this quote from the qmail security guarantee page: "Move separate functions into mutually untrusting programs...these programs don't even trust each other." Sound principle that also applies to djbdns. dnscache, tinydns, and walldns run as dedicated non-root UIDs inside chroot jails. dnscache is immune to cache poisoning. tinydns and walldns never cache information, nor do they support recursion.
Nice Features Make Happy Admins
dnscache is limited by default to a cache size of 1 megabyte. When it fills up, the oldest entries are discarded. It can be configured to send queries for a particular domain to a specific server or servers, such as internal servers behind a firewall.
tinydns does load balancing, and client differentiation, or directing clients to specific servers. Databases for tinydns and rbldns are compiled into cdb format, a fast, low-overhead, mission-critical-quality database written by- you guessed it, D.J. Bernstein.
djbdns features a brand-new client library, replacing the old BIND res_*/dn_* library. It dynamically allocates memory as needed, and is threadable and asynchronous, which means using fewer system resources and delivering more speed.
djbdns is the name of the entire DNS server package, a collection of daemons and support utilities. tinydns is the DNS content/ authoritative name server, dnscache is the caching-only recursive resolver. 'Tinydns' is cute and catchy, so it is often used as shorthand for 'djbdns'.
The differences between tinydns and dnscache are worth discussing, this is fundamental to understanding djbdns, and a major difference between djbdns and BIND.
DNS servers have two base functions: content servers and proxy servers. (oversimplified, but sufficient for now.) Content servers, like tinydns, axfrdns, walldns, and rbldns, publish DNS content to the world, served up from a database (such as cdb), or generated by the server. These servers handle incoming queries from the Internet, so they must be publicly accessible. Content servers don't need caches. This is what you use for managing your own DNS for domains and servers under your control, such as mail and Web.
Proxy servers such as dnscache serve the internal, or private network, and must not be publicly accessible. Usually they listen to the loopback address, or other non-routable IP. Proxy servers accept recursive DNS queries from local clients. They fetch data from content servers, they are the intermediaries between DNS clients and DNS servers. They use caching to speed up answering requests, and reduce network traffic. Forwarding proxy servers don't do name resolution, they talk to other proxy servers. This is useful over congested or slow data links, or when there is a firewall in the way.
It is very important to keep the two separated. Cache poisoning was a favorite BIND exploit, one of the most famous being when requests for www.internic.net were hijacked to sites belonging to AlterNIC. AlterNIC runs alternate root servers with top-level domains like .porn and .xxx. They weren't sneaky about it, and didn't try to pretend that their sites were InterNIC. They altered, or "poisoned", the caches of major name servers all over the world. It's a dirty trick, and it doesn't take much imagination to see how catastrophic this could be.
BIND 8.2 introduced a horrid authentication hack called transaction signatures, or TSIG, to handle this problem. djbdns takes the sensible approach: it follows the grand UNIX tradition of small, specialized programs working cooperatively. It separates the authoritative name server (tinydns) from the caching server (dnscache). A properly configured dnscache is impossible to poison, and if it ever is, it will affect nothing beyond dnscache itself.
djbdns runs on all Linux/UNIX systems, except SCO UnixWare. First step is to install daemontools, also a DJB production. daemontools manages all the djbdns services and daemons. Do it the way the instructions say, there is no room for ad-libbing: http://cr.yp.to/daemontools/install.html
Now go here to install djbdns: http://cr.yp.to/djbdns/ install.html. Good instructions, again do exactly what they say.
At this point, the road forks: if you know DNS, it's simply a matter of editing config files. If you don't know DNS.... well, that's a topic for another day. Next week, in fact. I'll walk through a simple configuration for a small network running a mail server, Web server, and proxy server.