About LWN.net

A look at djbdns

We received, shall we say, some mail on the topic, politely telling us that perhaps we had not looked closely enough at djbdns. Further investigation showed those claims to be accurate. So, as a form of penance, here is a much more detailed look at that system. There is, in fact, more to djbdns than first met the eye.

On overview

Mr. Bernstein, however, is confident enough of the security of djbdns that he is offering a $500 reward to the first person who turns up a security hole in the code.

Another common aspect of DJB code is program-friendly configuration files. Again, this is partly a security and reliability issue; Mr. Bernstein believes it is hard to do text parsing without running into trouble.

Finally, of course, there is DJB's licensing for his software. djbdns is "almost free," in that you can download it, compile it, and redistribute it. What you can not do, however, is distribute a version that is changed in any way. There are those who are not happy with that restriction, and it does tend to frustrate the free software development dynamic. Linus Torvalds keeps a tight grip (usually) on what he allows in the kernel, but there are no end of people distributing modified versions for one reason or another. Nobody can distribute a value-added version of djbdns in that way.

What people can do is distribute patches. Russ Nelson has set up a site at djbdns.org that contains various patches that people have contributed, pointers to commercial djbdns support providers, and more.

The components of djbdns

As has been mentioned, djbdns is a collection of small programs. They way they work will seem a little strange to an administrator who is familiar with BIND - djbdns has more than one kind of DNS server.

Here's some of what's available:

• tinydns is intended to be the authoritative server for one or more domains. It handles most UDP-base queries; it does not handle TCP queries, and it will not do recursive name resolution. Tinydns is explicitly not meant to answer queries from clients (web browsers, whatever); it really only wants to talk to other name servers. Thus, a /etc/resolv.conf file should never point to a tinydns server.

• dnscache is a caching DNS server which is intended to handle user queries. It possesses no authoritative data of its own. It takes great care to get authoritative answers starting from the root servers, and, thus, defends itself from cache-poisoning attacks. It will handle (and use) both UDP and TCP connections as needed.

• rbldns is a special server intended to efficiently handle "blackhole lists" such as RBL or DUL.

• axfrdns exists to handle TCP queries and zone transfers. It appears to be a bit of an afterthought - DJB does not see much need for TCP queries.

• walldns creates fake answers to IP address lookup requests; it's there for sites that wish to hide their internal network structure while still providing a reverse lookup for each of their IP addresses.

There are several other programs distributed with djbdns which help with configuration and operation of the system.

BIND administrators, of course, are used to running named for both the "authoritative name service" and "caching nameserver" roles. That means, of course, that anybody running named is usually dragging along a bunch of code that is not actually doing useful in any particular deployment. And that, in turn, is not a good idea in security-critical software. djbdns tries to get away from this problem by splitting those roles into separate processes.

Configuration

To somebody who has not had to do it, DNS configuration seems like it should be simple. After all, it's just a bunch of name/number pairs, right? Of course, it's not all that easy, and an amazing number of sites on the net get it wrong. The BIND configuration format does not help much; finding that missing period can be a frustrating exercise.

So an important aspect of any DNS server will be how easy it is to configure.

We'll start with dnscache, because it truly is easy. Usually all you have to do is to run it; it will take queries from the local host (only) and send back answers. If you're in the unfortunate situation where all your DNS queries have to go to another caching server somewhere, you set the FORWARDONLY environment variable before running dnscache, and put the IP address of the external cache in a file called servers/@.

If you want your dnscache to answer requests from outside, you have to set the IP environment variable to the IP address dnscache should bind to, then create an empty file for each subnet that can use the cache. If, for example, everything on the 192.168.1 subnet has access to the cache, create a file called .../ip/192.168.1.

The configuration for tinydns is more complicated, since it must be given the authoritative data that it is to serve. Those interested in the details of the format of the data file (called, simply, data) can get them from this web page.

In short, each line in the file corresponds to one sort of record that tinydns can serve. The first character of the line determines what kind of record it is; the rest gives the data in a colon-delimited format. Thus, a basic A record, which assigns an IP address to a domain name, would look something like:

	=nonesuch.lwn.net:192.168.1.1:

	+nonesuch2.lwn.net:192.168.1.1:

Similarly, @ configures MX records, & is for name server delegations, and so on.

There exists a whole set of little programs intended to make the data file easier to deal with. add-host, for example, adds a host entry to the file. But a DNS administrator is going to have to get into that file sooner or later.

There are a couple of nice features in tinydns. One is a simple access control mechanism which allows different data to be served to different parts of the net. It is a common practice to set up one server to be used internally, while another serves (limited) data to the net as a whole. tinydns can be set up, without too much trouble, to handle both tasks simultaneously.

There is also a "time stamp" feature which allows entries to be expired or enabled in the future. With time stamps, you can set up that midnight server changeover without actually having to stay up to make the change.

Performance

We are not equipped to do hard-core performance tests on DNS servers, so we have no data of our own to report. The following, for tinydns, may be found in the djbdns FAQ, however:

One site reported receiving 500 queries per second per server at peak times for data from a 350-megabyte data.cdb. The tinydns process handled about 7000 queries per second of CPU time. The CPU was a Pentium III-550.

This example, and lab tests, suggest that tinydns can easily handle the .com server load. However, I don't have enough data on the distribution of .com queries to carry out a realistic experiment.

There are similar claims for dnscache:

cr.yp.to, which among other things handles a million mailing-list deliveries in a typical week, has been using dnscache since Christmas 1999. In a typical 4-week period, dnscache used 128 minutes of CPU time on a Pentium II-350, handling 13.7 million queries and receiving 210 megabytes of data to cache.

I did a huge Internet survey through dnscache, handling nearly a million PTR queries for random IP addresses in 4.5 hours on a Pentium-133. In contrast, when I tried BIND instead of dnscache, BIND chewed up 32 megabytes of memory and crashed after barely more than 100000 lookups.

Until such a time as we can get Mindcraft to do one of their objective evaluations, we'll assume that djbdns is fast.

Conclusion

Whether it will find success as a BIND competitor is another question. DJB's mail system, qmail, has certainly found a wide community of users, and it has seen some high-profile deployments. But DJB is not a highly effective salesman for his software. Between licensing issues and a certain degree of arrogance, he has managed to create a sizable crowd of people who want nothing to do with his software. That may limit how far djbdns can go on the net.

In the end, though, you need not like Mr. Bernstein to make good use of his software. The net has a crying need for alternatives to BIND, and djbdns looks like the best one that is currently available and ready to use. If dealing with DNS is part of your job, you may well want to have a look.