DNS and "The djb Way"

Wayne Marshall <guinix@yahoo.com>

Easy Nameserving on FreeBSD With djbdns

What's in a name? That's the whole purpose of DNS, the Domain Name Service, to answer just that question. Given some arbitrary hostname anywhere on the Internet, it finds its IP address (or the address of its mailserver, domain name server, etc.) And, less often, the reverse: given an IP address, find the associated domain/hostname. DNS is arguably the largest and most successful implementation of a distributed database system. Rather than a single enormous hostname database repository, the DNS database is scattered among thousands, perhaps millions, of cooperating systems, each responsible for answering the subset of queries specifically within its authority. Most Un*x systems in general, and BSD systems in particular, run some version or other of BIND, the "Berkeley Internet Name Daemon", to perform this service. For many, though, BIND is a bane--considered buggy, insecure, hard to configure, easy to screw up. And when BIND goes bad, it is as though networks simply cease to exist.

So then what's in the name: djbdns? For one thing, a mouthful of consonants, pleading for a vowel. How are you supposed to say this out loud, anyway? Otherwise, djbdns is Daniel J. Bernstein's package of DNS servers and utilities, and a worthy alternative to BIND. Bernstein is best known as the author of qmail, as well as a number of other infrastructure utilities with a reputation for outstanding security, reliability and high-performance.

Following what may be called "the djb way", as exemplified by qmail, djbdns is a compact, cohesive and modular system, with a small number of purpose-built components each designed to do its particular job securely, reliably, and fast. This makes it easy to set up only those DNS services required for a particular host or network, while limiting a system's exposure to the potential vulnerablities of a monolithic, do-everything alternative like BIND's "named".

For example, your Internet-connected FreeBSD laptop can be set up with a simple and effective DNS cache. This will efficiently build up a local repository of nameserver responses, instead of generating extra network traffic to your ISP's nameserver. Similarly, a single server on your local network can be used to cache and share domain name lookups for all the clients on that network. And if you want to publish DNS information yourself, djbdns can provide for that as well, painlessly serving names for all the hosts on a private or public network.

This article will consider a few of these scenarios and demonstrate the easy set up and configuration of djbdns on FreeBSD. We will also crack open the door for a peek at "the djb way", an alternate parallel universe of doing things Un*x. The first look is weird and scary, but after a while "the djb way" may even begin to make sense (and that can be scary, too!)

Installation

An essential feature of "the djb way" is building from source; you generally won't find any precompiled packages. Fortunately, as with all of Bernstein's source code, djbdns is generic, non-proprietary, unadorned C, and will build fine following its own installation instructions on just about any Un*x system out there.

But djbdns is also good case for taking advantage of the FreeBSD ports system. Not only will the djbdns port fetch, patch, build, install, and register the system, it will also grab and install a collection of man pages to go along with it; these are otherwise not included with Bernstein's source distribution. To benefit from these advantages, we will illustrate installation with the FreeBSD ports system.

First, if you have not already done so, install the pre-requisite "daemontools" package, also from Bernstein. The ports build of djbdns will handle the dependency, but see also the Appendix to this article for more information on installing and configuring the daemontools package.

Building and installing djbdns is then as simple as issuing the following commands as root:

	# cd /usr/ports/net/djbdns
	# make
	# make install

	# pw groupadd nofiles -g 800
	# pw useradd dnslog   -g nofiles -u 810 -d /nonexistent -s /sbin/nologin
	# pw useradd dnscache -g nofiles -u 811 -d /nonexistent -s /sbin/nologin
	# pw useradd tinydns  -g nofiles -u 812 -d /nonexistent -s /sbin/nologin

That's it! Now djbdns is ready to go. All we need to do is to decide how we would like to use it.

Configuring a local DNS cache

Consider that a domain name service may be segregated into two separate functions. One, that may be called the "resolver", is responsible for performing hostname/address lookups among the DNS databases distributed over the Internet. The second function, that may be called the "publisher", is responsible for providing the DNS data associated with a specific set of hostnames/addresses.

More simply, the resolver part of a DNS system performs the queries, while the publisher part of the system answers those queries.

In the djbdns package, the resolver is called "dnscache". At the request of client programs, such as your web browser or mail transport agent, dnscache will perform recursive hostname/address resolution queries among authoritative nameservers on the Internet. For efficiency, dnscache then stores all the responses it gets in local memory cache, so that future queries can be answered quickly, and without duplicating the network traffic for subsequent queries.

One of the easiest and most effective uses of djbdns, then, is to set up just such a DNS cache on your workstation. For example, instead of pointing your FreeBSD laptop at a nameserver on your ISP's network, you can run dnscache and benefit from building a cache of hostname/addresses on your own machine.

Such a configuration is no-duh simple. As root, run the following commands:

	# dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1
	# ln -s /etc/dnscache /var/service
	# echo 'nameserver 127.0.0.1' >/etc/resolv.conf

	# nslookup - 127.0.0.1
	Default Server:  localhost
	Address:  127.0.0.1

	> www.freebsd.org
	Name:    www.freebsd.org
	Address:  216.136.204.117

What is happening with the configuration steps described above? The "dnscache-conf" command automates the setup of run scripts for daemontools, and has four arguments: the user name the dnscache binary will run under (dnscache), the user name the logger will run under (dnslog), the dnscache configuration and log directory (/etc/dnscache), and the IP address that dnscache will bind to (127.0.0.1).

The next command links the dnscache configuration directory just created by dnscache-conf, to the daemontools service spool directory, /var/service. Now dnscache will run under the control of daemontools, with all the utilities available to start, stop, suspend, and check the status of the service that daemontools provides.

Finally, putting the localhost address in "/etc/resolv.conf" points client programs to the dnscache resolver on your workstation. All lookup queries requested by your web browser, ftp client, and so forth, will now be done by your very own dnscache.

Configuring a shared DNS cache for a local network

Having your own personal dnscache is kinda cool, and a great way to get started with the djbdns package. But pretty soon you may want to share a DNS cache among several machines on a network. For example, consider a firewall-protected local network that includes a number servers and Windows clients. By providing a common DNS cache on this network, you can speed up queries for all your local clients, significantly reducing the DNS traffic going across the gateway.

Configuration is almost as easy as the first example. Here we will assume you are going to run dnscache on your FreeBSD server with a local network address of 10.0.1.53. The following commands will set this up:

	# dnscache-conf dnscache dnslog /etc/dnscache 10.0.1.53
	# touch /etc/dnscache/root/ip/10.0.1
	# ln -s /etc/dnscache /var/service

	nameserver 10.0.1.53 

The size of the cache used by dnscache is configurable. By default, it is one million bytes. To increase it to, say, 32 million bytes, do the following:

	# echo 32000000 > /etc/dnscache/env/CACHESIZE
	# echo 34000000 > /etc/dnscache/env/DATALIMIT
	# svc -t /var/service/dnscache

Configuring DNS cache with a private nameserver for a local network

The configuration above uses dnscache to query existing nameservers on the Internet to resolve hostname/address lookups. This is great for publicly accessible addresses, but doesn't do much good for finding hostnames on your own local network. For small simple networks, you could resort to simply copying a common "/etc/hosts" file to all the hosts on the network. But now that you have access to djbdns and this fine article, you will probably want to set up a bona fide nameserver for your local network instead.

The "publisher" component of the djbdns package is called tinydns. The "tiny" in this name should not be taken as an indication of its capabilities or performance, but in relation to its size and resource consumption. In fact, tinydns is quite powerful. Bernstein cites the case of two domain hosting companies using tinydns that together comprise over half a million addresses on the Internet!

The configuration described here will build on the external DNS cache configuration running on host 10.0.1.53 described above. But we will now add tinydns to this system, using a private loopback address of 127.53.0.1. To make this IP address available for tinydns, edit "/etc/rc.conf" and add the following line:

	ifconfig_lo0_alias0="inet 127.53.0.1 netmask 0xffffffff"

	# tinydns-conf tinydns dnslog /etc/tinydns 127.53.0.1
	# ln -s /etc/tinydns /var/service

Next, configure dnscache to direct lookup information for the local domain to this private tinydns server:

	# echo '127.53.0.1' > /etc/dnscache/root/servers/example.org
	# echo '127.53.0.1' > /etc/dnscache/root/servers/1.0.10.in-addr.arpa

The next step is to load the local tinydns database with the hostname information for the local example.org network:

	# cd /etc/tinydns/root
	# ./add-ns    example.org  127.53.0.1
	# ./add-ns    1.0.10.in-addr.arpa  127.53.0.1
	# ./add-host  dagwood.example.org  10.0.1.53
	# ./add-host  blondie.example.org  10.0.1.1
	# ./add-alias mailhub.example.org  10.0.1.1
	# ./add-host  dithers.example.org  10.0.1.254
	# ./add-alias bastion.example.org  10.0.1.254
	# make

Now restart dnscache (a good idea to restart the cache after any updates to the local tinydns database, in order to purge any failed queries that should now succeed):

	# svc -t /var/service/dnscache

	# nslookup - 10.0.1.53
	Default Server:  dagwood.example.org
	Address:  10.0.1.53

	> blondie
	Non-authoritative answer:
	Name:    blondie.example.org
	Address:  10.0.1.1

	domain example.org
	nameserver 10.0.1.53

	option domain-name "example.org";
	option domain-name-servers 10.0.1.53;

	# arp -a

Administration

As with most things "djb", the djbdns utilities don't require much in the way of intervention and on-going administration. Once they are set up, they just run.

Although dnscache/tinydns work fine with the standard DNS clients, such as nslookup(8) and dig(1), djbdns also installs its own query tools as well: dnsip, dnsipq, dnsname, dnsmx, dnstxt, dnsqr, dnsq, and dnstrace. The dnsip(1), dnsipq(1), and dnsname(1) utilities are particularly useful for calling from shell scripts. For debugging and checking your setup, you can use:

	$ dnsqr any dithers.example.org

	$ dnsq any blondie.example.org  127.53.0.1

For easily maintaining large DNS databases, you shouldn't have to wonder if there are any solutions for using SQL with tinydns. Of course there are several, including PostgreSQL and MySQL. See the "Life with djbdns" reference for pointers.

Periodically, you can look at the logs. If installed as above, monitor the dnscache log with:

	# tail -f /etc/dnscache/log/main/current

	# tail -f </etc/dnscache/log/main/current | tai64nlocal

	# tail -f </etc/tinydns/log/main/current | tai64nlocal

	# mkdir /var/log/dnscache
	# chown dnslog:nofiles /var/log/dnscache
	# chmod 1755 /var/log/dnscache

	#!/bin/sh
	exec setuidgid dnslog multilog t /var/log/dnscache

	# svc -k /var/service/dnscache/log

As for the organization of your filesystem hierarchy, you may have your own opinions about the installation layout described in the examples. Well okay, then. Other common layouts include installing under "/usr/local/etc" or "/var" paths, the former being the most likely "FreeBSD way". Collecting all the djbdns configurations under a common "./dns" or "./djbdns" directory is also a reasonable way of organizing things. Then you would use "/usr/local/etc/djbdns/dnscache" and "/usr/local/etc/djbdns/tinydns" for your installation directories in the above examples.

For administrative convenience, it's handy to have a simple daemontools control script for your djbdns services. Create a file named "dnsctl" that looks something like the following, put it in an executable path and chmod to, say, 750:

	#!/bin/sh
	# file /usr/local/bin/dnsctl
	# daemontools control script for djbdns services
	# wcm, 2002.08.26 - 2002.08.26
	# ===
	
	SERVICES="/var/service/dnscache /var/service/dnscache/log \
	          /var/service/tinydns  /var/service/tinydns/log"
	
	case "$1" in
	start)
	    echo "Starting djbdns services"
	    svc -u ${SERVICES}
	    ;;
	stop)
	    echo "Stopping djbdns services"
	    svc -d ${SERVICES}
	    ;;
	restart)
	    echo "Restarting djbdns services"
	    svc -t ${SERVICES}
	    ;;
	status)
	    svstat ${SERVICES}
	    ;;
	cdb)
	    echo "Updating tinydns data"
	    cd /var/service/tinydns/root; tinydns-data
	    ;;
	help)
	    cat << HELP
	  start -- start up djbdns services
	   stop -- stop djbdns services
	restart -- restart djbdns services
	 status -- view current status of djbdns services
	   help -- this screen
	HELP
	    ;;
	*)
	    echo "Usage: $0 [start|stop|restart|status|help]"
	    exit 1
	    ;;
	esac
	
	exit 0
	
	### that's all, folks!

	# dnsctl status

	# dnsctl cdb

That's about it: running djbdns is otherwise not very sweaty or exciting. But really, isn't that what you always wanted in a nameserver?

Conclusions

By using djbdns and the FreeBSD ports collection, we have made quick work of installing nameservers on single workstations and local networks. These make good platforms for having fun with DNS, and for testing different configurations to find the setup that best suits your purpose.

The next step in the progression of things is going public: setting up a couple of nameservers (primary and backup) to respond directly to queries from the Internet for your publicly addressable hosts. Doing this is not much more difficult than installing tinydns as described above, except that you will now be serving public IP addresses from an Internet-addressable host (rather than the private loopback address we used above.) For specific instructions on doing this properly, please get familiar with the additional documentation described in the "References" section. After your new nameservers have been set up and thoroughly tested, you will then coordinate with your upstream provider. They will add new NS records to their own nameservers, delegating nameserving authority for your domain on down to you.

The djbdns package is feature-full and offers several other utilities and services not described here. These allow large sites to set up and transfer zones, balance load among several nameservers, and provide additional security on firewall-protected public networks. Such capabilities make djbdns fully scalable, from the single workstations and small local networks described in this article, to the largest network service providers in operation today.

However you use djbdns, you are sure to find it secure, reliable, fast, and trouble-free. As time goes on, you may even find yourself growing to appreciate "the djb way". And if djbdns doesn't get you quite that far, well, at least it has helped you out of a bind.

Appendix: Installing daemontools

Bernstein's daemontools package provides a set of utilities to set up, log and administer server daemons, like djbdns and qmail, easily and securely. With daemontools and Bernstein's ucspi-tcp utilities (not discussed here), it is possible to install just about any server, and easily create custom services, under a consistent and secure control mechanism, without using inetd, rc.local, and/or other various startup and run script methods.

As with djbdns, the FreeBSD ports system can be used to advantage with daemontools. For example, with FreeBSD 4.6, the following commands will fetch, patch, build, install and register daemontools-0.76, including Gerrit Pape's conversion of djb's html documentation to standard man page format:

	# cd /usr/ports/sysutils/daemontools
	# make
	# make install

	/usr/local/etc/rc.d/svscan.sh

	# mkdir /var/service

	# /usr/local/etc/rc.d/svscan.sh start

You should know that the FreeBSD port install of daemontools does some things that are distinctly not "the djb way"; that is, different from what you would get if you were to install the package according to Bernstein's instructions. This is because daemontools-0.76 sortof pushes the envelope on the whole djb thing, using Bernstein's most recent ideas for a filesystem hierarchy that most of us may not be quite ready for just yet. For example, with a Bernstein installation, the package is built and remains in place in a top-level /package directory, the executables are linked into a top-level /command directory, and services are linked into a top-level /service directory.

The FreeBSD port undoes djb's installation scheme in favor of "the FreeBSD way", as documented in hier(7). That is, executables are installed as usual in /usr/local/bin, with /var/service recommended as the service spool. Package management is of course handled by the native FreeBSD package system, recorded in /var/db/pkg.

Sidenote #1: djbdns port build options

Note that the FreeBSD port of djbdns also allows customization of the build with a few options. To see these, check:

	# make pre-fetch

	# make -DWITH_IPV6 

	# make -DWITH_DNSCACHE_DUMPCACHE

Sidenote #2: Distributing Bernstein

As mentioned in the article, you will generally install djb software from source, rather than from pre-compiled packages shipped with your OS's distribution CD-ROMs. Whether you agree with Bernstein's thinking in all this or not, "the djb way" adds its own interesting twists to the interpretation of open source licensing and software distribution.

To start with, you won't find a LICENSE file accompanying djbdns. The fundamental premise for Bernstein is the legal principle of copyright. That is, the author is the only person entitled to make and distribute copies of his work, unless and/or until he has waived, sold, licensed, or otherwise transferred these rights to others. (Bernstein's comments suggest he believes software licenses are unenforceable.)

If you obtain a copy of his software by downloading from his server, Bernstein's asserts that it is not you who has made the copy. Rather, Bernstein would say he has made the copy for you, as is his right as author to do so, by way of his instructing his server (through its configuration) to provide you with the download. Once you have ftp'd the source, then, you have legally acquired a copy of the software from the author, with his permission. And Bernstein has not relinquished or transferred any of his own copyrights to you in the process.

Now that you do legally "own" a copy of the software, Bernstein maintains that you have a set of legally sanctioned rights and priveleges regarding what you can do with it. These include making backups, applying patches and modifications and compiling and running the programs, all without the need for additional permissions from the copyright holder. (These are the rights and priveleges that Bernstein claims apply to any software, commercial or otherwise, as based on 17 USC 117, irrespective of any so-called license on the shrink-wrap.) Among the rights you do not have in this scheme is the right to turn around and copy the software yourself for distribution to others. Although you are free to apply and distribute your own patches and modifications however you would like, you are not entitled to redistribute the original or modified work, derivations, and/or compiled binaries, unless you have been granted specific permission to do so.

If we stop at this point, the principles regarding distribution under "the djb way" certainly do seem more restrictive than those granted under the Berkeley or GNU licenses. In particular, CD-ROM distributor's feel they have a problem when they want to include Bernstein's programs with their products.

In actual practice, though, "the djb way" does little to impair most user's ability to access and freely enjoy the harvest of Bernstein's labor, in whatever way one could choose. (For one thing, as we will see shortly, Bernstein does make it possible for mirrors and distributors to include his programs.) It is even possible to consider certain possible benefits in this scheme, by way of the author's control over source consistency and distribution integrity. These are certainly not trivial concerns these days, particularly with software so critically central to system security.

And here is where Bernstein now goes further and does something extaordinary. He offers a "security guarantee", backed by a $500 reward (unclaimed, as far as I know) for anyone who finds a security hole in his code! Now compare this to the bold print disclaimers of warranty you find in all your Berkeley and GNU licenses.

It would seem, then, that Bernstein is choosing to freely distribute his work under the legal umbrella of copyright as a means to protect the integrity and security of his projects. One could further interpret this strategy as an expression of deep, on-going and personal commitment to the quality of software. It would hardly be fair to object to the arrangement. Even where there are other means for managing projects in ways that are both secure and "open", they are not without their own costs and tradeoffs. For example, considering just the hassle factor of following up on claims that may be the result of unidentified forks and mutations, could Bernstein even bother to make his "security guarantee" without asserting the principle of copyright? And how many project developers of any slant, open source or otherwise, are offering cash rewards (and with their own personal money!) for finding flaws in their work? (Knuth's legendary rewards for TeX being the rare precedent.) Speaking as a happy and grateful user of djbdns, I feel the benefits derived from Bernstein's security guarantee far outweigh any of the restrictions, real or imagined, imposed by his copyright protection.

I say imagined because of this: Bernstein does in fact provide explicit permission for the redistribution of his code, in both source and compiled form. Check his website, and you will find it in black and white (style sheets not yet being a feature of html in "the djb way".) In the case of djbdns, for example, Bernstein grants permanent, unrestricted permission to anyone to distribute exact copies of the source archives. And pre-compiled binaries may also be distributed without restriction, with the provision they are exactly as would result from a standard installation from source. (Note also that Bernstein has completely released some of his other work, such as "cdb", into the public domain.)

In the end, whether you are a user or distributor, lawyer or philosopher, it would be hard to find a practical downside in any of this. Adherents of "the djb way" will download, patch, and build from original source in any case. But it's a wide world, of many persuasions and passions, with many choices of freedom. For me, "the djb way" is only one way of many providing for the propagation of fantastic, free software through the cyber-ecology, increasing the richness and diversity of our systems in the process.

Resources and Further Information

Dan Bernstein's web site, the source for djbdns, daemontools, and related information: http://cr.yp.to/

Henning Brauer's "Life with djbdns" website: http://lifewithdjbdns.org/

Russell Nelson's "unofficial" djbdns website: http://www.djbdns.org/

Felix von Leitner's "unoffical" FAQ, and other resources such as an IPv6 patch: http://www.fefe.de/djbdns/

Florent Guillame's "dumpcache" patch: http://mapage.noos.fr/efge/djbdns/

Gerrit Pape's man pages derived from Bernstein's HTML documentation: http://smarden.org/pape/djb/

About the Author

Wayne Marshall (guinix@yahoo.com) is a Unix programmer and technical consultant in Guinea, West Africa. He and his wife enjoy traveling and living in Africa.