djbdns: More Than Just a Mouthful of Consonants

Let's face it, DNS is not the most sexy component of the Internet's infrastructure. It is an old technology and doesn't get the same attention as newer, more flashy tools and software. Your Web site visitors may comment on how cool your new AJAX widget is, but I guarantee they will never tell the world how pleased they are with your DNS response time.

Nevertheless, DNS is crucial to the Internet. It is one of those services that always should “just work”, and it's only when it doesn't work that people notice (and complain, loudly). Readers may remember the great “Google vanishing act” in May 2005, when the search engine giant briefly disappeared from the Internet. Many quickly assumed the site had been hacked, but the problem turned out to be a DNS configuration issue. The mishap was fixed quickly, but it highlighted how even the mightiest of the mighty can be crippled easily by a simple misconfiguration.

My primary goal for this article is to demonstrate that there is a free, secure and easy-to-configure alternative to BIND: djbdns. This article is intended for people who may have some experience with DNS, but who would like to consider new approaches. I assume only a basic understanding of DNS—specifically, familiarity with the basic record types, such as A, CNAME, MX, NS and SOA, as well as the concept of a TTL (time to live).

For the first 15 years of the Internet as we know it, there was only one real choice when it came to DNS server software: BIND. BIND began life as a project by several graduate students at the University of California, Berkeley (thus the acronym, the Berkeley Internet Name Domain). In the early 1990s, the Internet Systems Consortium (ISC) was created to maintain, distribute and support this critical software formally. The ISC released BIND 8 in May 1997 as a major update to the aging BIND 4. Although there were major configuration differences, both BIND 4 and 8 were based on the original Berkeley code from the early and mid-1980s. While trying to raise funding for a major rewrite, one of BIND's authors described this code as “sleazeware produced in a drunken fury”. A new team worked on the rewrite for several years, and BIND 9 was released formally in September 2000.

After years of dealing with security problems in BIND and frustration with its configuration syntax, Dan J. Bernstein began work on djbdns in 1999. Bernstein (or DJB as he is commonly known) already had made a name for himself as the author of qmail, the mail server software that was quickly gaining popularity among system administrators. At the time, Sendmail was the dominant mail server on the Internet, and, like BIND, it was notoriously difficult to configure and had a history of security problems. Bernstein's “thinking outside the box” design decisions about security and configuration simplicity not only catapulted qmail to success, but it also affected the way developers thought about writing software for the increasingly volatile Internet (Postfix, Courier and others were inspired by qmail's security partitioning design). Now that Bernstein had secured and simplified mail, it was time to do the same for DNS. The first alpha of djbdns was released in December 1999, and the current version, djbdns 1.05, eventually was released on February 11, 2001. That's right, the current version is more than seven years old. Remember, DNS is an old protocol, and it doesn't change very often. BIND software updates almost always are for bugfixes or security patches.

In the past, Bernstein's software was controversial because it lacked an explicit license. OS vendors were reluctant to distribute his packages because of the uncertainty around its licensing. However, in December 2007, Bernstein placed djbdns (as well as daemontools and qmail) into the public domain, allowing people to use or distribute it as they see fit.

BIND has been around since the earliest days of the Internet. It's still the most popular DNS server out there, so why should you consider switching to djbdns? For one, djbdns does not have BIND's history of problems. BIND's security record is on par with Sendmail's (not something to be proud of), and configuring it beyond the basics can be downright painful.

To complicate things further, BIND blurs the distinction between the different functions of DNS. There are two primary types of DNS services: DNS caches (also called recursive DNS servers) and DNS servers (also called authoritative servers or name servers).

A DNS cache is what your desktop computer talks to when it needs to find the address for a Web site you are trying to reach. When a cache receives your request for the location of www.google.com, it first checks to see whether it already knows the answer to your question. If it does, it quickly tells you. If it does not know the answer already, it begins by first asking the root servers for the answer. The root servers respond with something similar to “I don't know the answer but the .com servers might; here are their addresses, go ask them.” The caching server continues doing this until it has the IP for www.google.com, and then it returns the answer to your computer. The IP addresses you see in /etc/resolv.conf are for DNS caches. Caches talk to authoritative servers to get answers.

An authoritative server has a much more straightforward responsibility. Its job is simply to publish information from domains for which it is “authoritative”. An authoritative server will give answers only to questions about domains for which it has been explicitly configured. For example, ns1.google.com (one of Google's authoritative DNS servers) never will answer a request for the address of www.microsoft.com (unless Microsoft and Google merge some day).

Although these are completely different services, BIND uses the same server for both. This may seem handy, but it complicates the configuration and quickly can become a security headache.

On the other hand, djbdns adheres to the UNIX philosophy of “do one thing, and do it well”. The server components of djbdns are separated, with dnscache as the caching component and tinydns as the authoritative server (I detail the advantages of each shortly).

This separation allows each program to run individually chrooted as its own unprivileged user. If an attacker is able to crash your DNS cache, it will not impact your authoritative DNS service. A side effect of this is that dnscache and tinydns need separate IP addresses, so that each may bind to port 53. You can't run both on the same IP address.