Personal tools
You are here: Home OpenPKG djbdns
Log in

Forgot your password?
Document Actions


by zoperoot last modified 2007-11-05 01:07
DNS -- Domain Name Service

DNS using djbdns

DNS (Domain Name Service) is the backbone of the Internet, and any IP based system. It's the means by which meaningful domain and host names are turned into numeric IP addresses, and IP addresses translated back to FQDNs (Fully Qualified Domain Names). For years BIND (Berkeley Internet Name Daemon) has been the standard method of maintaining and resolving these addresses. Unfortunately BIND has also taken sendmail's place as one of the primary security hazards on the Internet.


The djbdns program is an alternative to BIND, and offers many advantages, notably security, speed, simplicity, and security (to paraphrase ``Blazing Saddles'' -- kinda like that security). A major reason for the increased security is that djbdns consists of several small programs, each of which handles a specific job instead of doing everything in one huge, monolithic program that does everything. This means that there's a bit more work to do to set up djbdns than to set up BIND (beyond the fact that BIND is pre-installed on most Unix-type systems). All the djbdns servers run as non-root users with limited privileges.

The most daunting aspect of djbdns is that each server requires its own IP address (with one exception that I'll address later). This requires some mental adjustment, and planning, but isn't difficult to implement.

Server Descriptions

dnscacheDNS name resolution (find any address)
tinydnsDNS Authoritative Info (supplies domain information)
axfrdnsSupplies zone info to BIND servers.
rbldnsRBL server with very simple data format

The ``dnscache'' program does DNS resolution, and is the minimum requirement for a machine to operate on an IP network. It is installed at the IP address referenced in the /etc/resolv.conf file, often the loopback interface, The dnscache server doesn't supply any authoritative data, and should generally not be accessible by the world at large. At a minimum, dnscache will look up addresses from the root name servers, and can also be directed to local content servers to get the information for locally maintained domains.

The ``tinydns'' program is a ``content'' server, and supplies authoritative DNS information from files on the system. It doesn't do any address resolution (this is done by dnscache). This will be running on at least one public address for a domain, the address specified in the NIC records as a name server. One can run multiple copies of tinydns on a system to implement ``split-horizon'' DNS where private DNS is maintained separate from the public records.

The axfrdns program allows zone transfers from remote BIND programs from the same data files used by tinydns. This is only necessary to support secondary servers running BIND as djbdns usually maintains multiple servers using rsync instead of zone transfers. This server normally runs on the same IP address as the public tinydns, and services TCP requests while tinydns only services UDP.

The rbldns program provides RBL (Realtime Blackhole List) lookups. These provide a fast way to identify hosts by their IP address that are either to be denied or allowed access. The input to rbldns is a flat ASCII file with IP addresses and CIDR network specifications ( would specify a full class C network). These are very easy to maintain compared to using BIND, and should be much faster responding to queries.

The rootdns program runs a local copy of the root domain information which is faster, and cannot be polluted by somebody cracking or spoofing the root servers.

Assigning IP Addresses to Servers

This requires a bit of planning, and depends on the function of the system where the server(s) running.

  • A single machine on the Internet that doesn't supply any external information may just have dnscache running on (localhost).

  • A machine supplying DNS lookup services to other machines on its network, but no other services, then dnscache would be run on the primary IP address on the LAN.

  • A machine supplying authoritative data would run tinydns on a public IP address, and dnscache on either or a private IP address to do address resolution. It might also run another copy of tinydns on (another localhost) with private authoritative data to handle ``split-horizon''. This machine would also run axfrdns to support zone transfers as required.

    One could run multiple copies of dnscache on a machine to provide pure resolution on one IP address, and split-horizon on another.


Several of our machines support multiple public interfaces for DNS servers for historical reasons (a polite way of saying that I screwed up while learning DNS and there are people using us for secondary services where we don't want to change the NIC records). One of these machines,, has servers set up as follows:

tinydnstinydns192.136.111.59Public NS
axfrdnsaxfrdns192.136.111.59Public NS Zone Transfers
tinydns2tinydns192.136.111.2Public NS
axfrdns2axfrdns192.136.111.2Public NS Zone Transfers
tinydns-privatetinydns127.0.0.3Private NS for
dnscachednscache192.168.253.253Local DNS resolution
rootdnstinydns127.53.0.1Local copy root DNS info

Here we have tinydns running on two public IP addresses, and axfrdns on the same IP addresses to support zone transfers. We have tinydns running on a localhost IP to provide DNS information for our local sub-domain. The dnscache program does lookups for all systems on our internal LAN, and has explicit links to the two tinydns and rootdns servers running on the same machine.

My laptop machine is much simpler. I have it configured so that it will run reasonably when totally disconnected from the Internet. Here I've combined our public and private data into a single file served up by one copy of tinydns, and everything runs off of the 127/8 localhost network. It won't do lookups for anybody else.

dnscachednscache127.0.0.1Local DNS resolution
rootdnsrootdns127.53.0.1Local copy root DNS info
tinydnstinydns127.0.0.2Public and private NS

Installing Software on Caldera Linux Systems

djbdns uses daemontools to start, monitor, and control the DNS services. Before running djbdns you need to install daemontools 0.70 or above.

You will also need to install ucspi-tcp if you want to use axfrdns or axfr-get.

I have RPMS for daemontools, ucspi-tcp, and djbdns on compiled for various flavors of Caldera Linux. These RPMS include manual pages in addition to the software, and the daemontools rpm makes the necessary changes to /etc/inittab to have svscan run automatically.

  1. OpenLinux 1.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.

  2. OpenLinux 2.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.

  3. eServer 2.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.

  4. eDesktop 2.4 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.

  5. Source RPMS daemontools, ucspi-tcp, djbdns, and BIND and file utilities.

Down load the appropriate files, login as root, and install them using the commands:

rpm -i daemontools*.i386.rpm
rpm -i djbdns*.i386.rpm
rpm -i ucspi-tcp*.i386.rpm

Assuming that everything goes according to plan, you should now have a /service directory with the svscan program running to monitor daemon processes.

Installing and Starting Servers

Add DNS Users

One of the reasons that djbdns is more secure than the default installations of BIND is that every server runs with limited privileges. The first step then is to create these users. Assuming that you're going to run all the servers, and have each group of servers with its own user name. These commands will do the minimum necessary to create these users. Delete the ones you're not going to use.

useradd axfrdns -s /bin/false
useradd dnscache -s /bin/false
useradd dnslog -s /bin/false
useradd rbldns -s /bin/false
useradd tinydns -s /bin/false

dnscache -- caching DNS resolver

Select the appropriate IP address for the resolver. Here I'm going to install it on the internal LAN interface where it's accessible by anybody on the internal LAN. For the purposes of this assume that the internal LAN's on the private class C, and this machine's on

# Create /csoft/etc/dnscache with all necessary files
dnscache-conf dnscache dnslog /csoft/etc/dnscache
# Tell dnscache to listen on the network
touch /csoft/etc/dnscache/root/ip/192.168.253
# Svscan will automatically start the daemon within 5 seconds
ln -s /csoft/etc/dnscache /service

Add dnscache Server to /etc/resolv.conf

Now if you put the line ``nameserver'' as the first nameserver line in /etc/resolv.conf you should be able to resolve IP addresses using the new dnscache server.

Enable Access to dnscache for Specific Networks

This server will only listen to UDP DNS requests from networks specified by files in the /csoft/etc/dnscache/root/ip directory. The dnscache-conf program creates one for the 127/8 localhost network, and you will have to create files for other valid networks which is what the ``touch'' command does above for the private network. We also have files on our LAN here at Celestial for and, our public networks.

Extensions to dnscache

The RPM for dnscache from Celestial is built with a couple of patches from Uwe Ohse's patches to djbdns which allow one to set the OKCLIENT environment variable to allow any client to access dnscache, and to have dnscache listen on multiple IP addresses which can be useful on dual-hosted machines.

To allow dnscache to answer requests from any client add a line to /csoft/etc/dnscache/run at the top of the file:


To have dnscache listen on multiple interfaces, use a comma separated list of IP addresses on the dnscache-conf command line (no spaces around the commas), or edit the /csoft/etc/dnscache/env/IP file manually.

Restart dnscache Server

You will need to restart the dnscache server after making any changes in its configuration files. This is done with the command:

svc -du /service/dnscache

tinydns -- Authoritative DNS Server

The tinydns program is a content server that supplies DNS information only for those zones for which it is authoritative. This is the server to run on the public DNS server IP addresses to service requests for DNS information in the zones for which it's responsible.

Tinydns doesn't do any recursive lookups, so cannot be used in the /etc/resolv.conf file for general resolution.

Internal private domains require their own tinydns server that is accessible only from the private network. It's easy to run ``split-horizon'' DNS on the internal networks since dnscache can look to the private tinydns server for the internal addresses, and the public tinydns server for the public ones.

Select IP Address and Create Servers

Select the appropriate IP address for tinydns servers. There may well be multiple servers on a single host as describe in the Examples section. Each public DNS server IP address requires its own copy of tinydns, and another private tinydns server's necessary to implement split-horizon DNS. I'm going to use a private IP address, in the example below to prevent any potential problems with people doing cut-n-paste from this documentation on real servers. The domain ``'' is used for the same reasons.

The convention we use is that the first public server will run from /csoft/etc/tinydns, and the private in /csoft/etc/tinydns-private. Additional public servers will run in /csoft/etc/tinydnsN where N then number of the server (it doesn't matter what this is so long as it's consistent and unique to that server). When I configure multiple servers this way, I set the secondary servers to share the same data files by linking their root directories to /csoft/etc/tinydnscache/root.

tinydns-conf tinydns dnslog /csoft/etc/tinydns2 $IPADDR
rm -f /csoft/etc/tinydns2/root
ln -s /csoft/etc/tinydns/root /csoft/etc/tinydns2/root

Normally there will only be one private server, unless there's a need to have multiple private domains. In this case, it's probably best to have the local private domains responsible for their own files rather than have a centralized location which might be more difficult to maintain. The private server will run on a localhost IP address since it will only be accessed by the dnscache program on that machine.

# Create /csoft/etc/tinydns with all necessary files
tinydns-conf tinydns dnslog /csoft/etc/tinydns $publicip
# Tell dnscache where the public info is available
echo $publicip > /csoft/etc/dnscache/root/servers/$pubdomain
# create private tinydns server
tinydns-conf tinydns dnslog /csoft/etc/tinydns-private $privateip
# Tell dnscache where the private info is available
echo $privateip > /csoft/etc/dnscache/root/servers/$privdomain
# Svscan will automatically start the daemons within 5 seconds
ln -s /csoft/etc/tinydns /service
ln -s /csoft/etc/tinydns-private /service

Zone Files

The configuration files for djbdns are considerably simpler than those for BIND as well. Small shops that only have to do DNS for a few domains can add hosts with a single line in a file instead of having to update multiple files as required by BIND. See Life with djbdns Simple Setup for some simple examples of the configuration files. I'm going to address this further in the section on maintaining multiple zones below.

Restart tinydns Server

You will need to restart the tinydns servers after making any changes in their configuration files. This is done with the commands:

rbldns -- Realtime Blackhole List DNS Server

The rbldns server is designed to maintain DNS lists of host IP addresses for fast lookup by mail servers, and other clients that permit them to ALLOW or DENY access depending on whether the IP address is in the list. Historically this has been implemeted to limit e-mail abuse groups with tools like Mail Abuse Prevention System MAPS RBL Realtime Blackhole List, MAPS DUL Dialup Users List, and MAPS RSS Relay Spam Stopper

Maintaining an RBL using standard BIND was messy and ineffient as the files tend to be large, and updating took quite a while. The rbldns program simplifies this drastically since it uses a single data file containing IP addresses and CIDR blocks, one per line. The rbldns server is designed to do one thing very efficiently so it doesn't have the overhead associated with a full content server.

The RBL servers are supported through programs like tcp_wrappers, rblsmtpd (part of the ucspi-tcp package), and other programs using the tcp_wrappers libraries (smail-3.2 uses this). The way this works is that an IP address is converted to an RBL entry by reversing the order of the octets, and appending the RBL name Thus -> in Celestial's local RBL of hosts that have connected to us to send unsolicited e-mail. All lookups that are in the RBL return the same IP address, typically

The /etc/hosts.allow lines we use for the anti-spam RBLs are:

# local RBL, mostly systems that have hit our spam traps
sendmail,smtpd: {RBL} : DENY
sendmail,smtpd: {RBL} : DENY
# MAPS DUL (Dialup Users List)
sendmail,smtpd: {RBL} : DENY
# MAPS RSS (Open Relays that have sent spam).
sendmail,smtpd: {RBL} : DENY
sendmail,smtpd: {RBL} : DENY
sendmail,smtpd: ALL : ALLOW

Select IP Address and Create Servers

Each rbldns server needs to run on its own IP address, usually public, and must have corresponding NS entries it its parent domain if it's to be publically accessible.

rbltxt="Local RBL List"
rbldns-conf tinydns dnslog /csoft/etc/rbldns $pubip
echo $pubip > /csoft/etc/dnscache/root/servers/$rbldomain
# Create IP address and description in file
echo ":$rbltxt" > /csoft/etc/rbldns/root/data
# now create the database
gmake -C /csoft/etc/rbldns/root
# finally link it to /service so that the daemon will start
ln -s /csoft/etc/rbldns /service
# restart dnscache so that it will recognize rbldns
svc -du /service/dnscache

axfrdns -- Server for BIND Zone Transfers

The axfrdns program runs on the same IP address as the tinydns server, and uses its data files to provide zone transfers to BIND systems. It listens on the TCP port of the IP address while tinydns listens on the UDP port.

It isn't necessary to run axfrdns if all the name servers for your domains are using dbjdns because they will keep their files synchronized using the rsync program.

Create axfrdns Servers

There will usually be one axfrdns server for each public tinydns server on a system. These can be added at the same time as the tinydns servers or later using these commands:

axfrdns-conf tinydns dnslog /csoft/etc/axfrdns /csoft/etc/tinydns $publicip
ln -s /csoft/etc/axfrdns /service

Edit the axfrdns Configuration File

One file, /csoft/etc/axfrdns/tcp, controls what servers are allowed to do zone transfers from the axfrdns server. Each axfrdns server gets its zone information from a corresponding /csoft/etc/tinydns/root directory.

This will have a line for each host with a list of the zones it can transfer:

# sample line:
# ...

Run ``gmake -C /csoft/etc/axfrdns'' after editing this file to build the /csoft/etc/axfrdns/tcp.cdb file.

You can link the /csoft/etc/axfrdns/tcp* files to other multiple axfrdns servers if necessary so that there's only one file to edit for all the axfrdns servers running on a machine.

Maintaining Multiple Domain Files

I am putting together a system to maintain multiple zone files using the Unix file system as the primary database, with simple shell scripts to maintain the data files by combining the individual zone files. The djbdns files are designed to be simple to edit and maintain, and personally I find it easier to edit a file than to dig through a bunch of browser screens to do a simple task. All the djbdns files are under the /csoft/etc/djbdns directory in these subdirectories and files:

primaryzonenamedatastandard djbdns data for zone
primaryzonenameupdate.shScript to update secondaries
secondaryzonenamedatastandard djbdns data for zone
secondaryzonenameaxfrcmdScript to do zone transfer if necessary
privatezonenamedatastandard djbdns data for zone
pubdirdata standard djbdns for primary and secondary zones
privdirdata standard djbdns for private zones

This allows us to build public and private data files simply with scripts like this:

sort -u primary/*/data secondary/*/data > pubdir/data
(cd pubdir; tinydns-data; rsync...)
sort -u private/*/data > privdir/data
(cd privdir; tinydns-data; rsync...)

Primary Zone Files

The primary zone's data files can be maintained any way that seems appropriate including the simple shell scripts that the tinydns-conf program creates in the /csoft/etc/tinydns/root directory. Creating a new zone could be as simple as:

cd /csoft/etc/djbdns
mkdir primary/
cd primary/
touch data
tinydns-edit data add ns
tinydns-edit data add ns
tinydns-edit data add host
tinydns-edit data add host
tinydns-edit data add host
tinydns-edit data add mx
tinydns-edit data add mx
tinydns-edit data add mx

This is a bit rudimentary, but should work. It has the MX records hard coded instead of with host names which will work, but I prefer to keep it a bit cleaner than that.

The script could be used to update ``secondary'' servers after making changes in the data files. This could also be in a ``Makefile'' that would also handle things like running tinydns-data as necessary.

Secondary Data Files

These are normally updated from the primary systems, either directly using rsync from those systems, or by doing zone transfers from their BIND servers.

Private Data Files

These are exactly like the primary data files except that they're destined for the /csoft/etc/tinydns-private/root/data for split-horizon DNS instead of for external use.

Purely private tinydns

There may well be self-contained machines such as laptops that are often used as disconnected from the net. These might well run a single tinydns program using the zone files from the public, secondary, and private directories:

cd /csoft/etc/djbdns
mkdir selfdir
sort -u primary/*/data secondary/*/data private/*/data > selfdir/data
(cd selfdir; tinydns-data)

Rsync Server Configuration for Secondary Servers

Secondary DNS servers can be configured using /csoft/etc/rsync/*conf so that they can be updated safely using the rsync in server mode instead of using ssh, secure shell. This has the advantage that it doesn't require using ssh identity files with null pass phrases if one wants to run jobs from cron, and it avoids some problems where rsync may hang using ssh connections.

There are a couple of different configurations possible using rsync, syncing the entire /csoft/etc/tinydns and /csoft/etc/tinydns-private data files on multiple machines within a single organization, and sync'ing a set of zone files to another site's secondary directories where that site may have a superset of the zones maintained on your system. In the first case, the updates will go directly to the /csoft/etc/tinydns/root directory, while in the second they will go to /csoft/etc/djbdns/secondary/zonename (which could well contain multiple zones so a single directory could handle all zones for a site).

Building the /csoft/etc/dnscache/root/servers Files

There are some significant advantages to running local copies of the root name server information. This eliminates the need to go out on the Internet to the root servers for every lookup, and also provides additional security against corruption of the root servers. The Open Root Server Confederation provides complete instructions on setting up your own root name server info using djbdns. They also tend to have the latest information on new Top Level Domains (TLDs) before ICANN does.

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: