First of two parts
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:
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
BIND Guru Confusion
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
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
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.
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:
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.