djbdns: An alternative to BIND

Those who have been concerned with the
number of security vulnerabilities found in the BIND server through
the years, or who prefer an easier DNS solution, may wish to
investigate an alternative, djbdns. This software, written from
scratch by D.J. Bernstein, provides a much more robust, simplified
and secure framework for DNS. djbdns is easy to install and
configure, and is much less complex than BIND, essentially the same
functionality.

This article is excerpted from the newly published book “Linux Network Administrator’s Guide.”

A djbdns DNS server is designed to be just that, a DNS server, meaning that by default it won’t
be resolving queries for machines outside of your authority. For
that, you will need to build a separate caching server on a separate
machine or IP address. Caches and DNS servers
should be separated for security reasons.

Installing djbdns

To run djbdns, you first need to install another DJB program called daemontools, which is basically a collection of tools used to manage various Unix daemons. When you’ve successfully downloaded the software,
extract it to a directory on your machine and compile the software.
daemontools comes with a script that will automatically compile and
install the software. It can be launched as follows:

vlager# mkdir software
vlager# cd software
vlager# tar xzpf daemontools-0.76.tar.gz
vlager# cd admin/daemontools-0.76
vlager# package/install

When the script finishes, you can
remove the installation directories, and begin installing the next
dependency, ucspi-tcp, which is DJB’s very own TCP
client-server handling program. It is also very easy to install:

# mkdir software
# cd software
# tar xzpf ucspi-tcp-0.88.tar.gz
# cd ucspi-tcp-0.88
# make
# make setup check

This will install the software to the /usr/local
directory on your machine. You won’t need to do
anything else with the operation or configuration of this software
for the moment.

Once it is installed, you are ready to install the djbdns software. The
djbdns installation is accomplished using the same steps documented
above for ucspi-tcp. This process will also
install djbdns to the /usr/local directory. You
will need to make sure that the svscan process is
running before configuring djbdns. svscan is part
of the daemontools package and must be running for
djbdns to function.

When you’ve verified that svscan is running, you can start the
configuration of the DNS server. The first step is to create two user
accounts, tinydns and dnslog. djbdns will use both of these to conduct
its business, rather than run as root, as BIND installations often do.

Next, you will need to create a
directory for your DNS server’s configuration files
and logs, and then configure it as follows:

# mkdir /etc/tinydns
# tinydns-conf tinydns dnslog /etc/tinydns 172.16.0.2

The IP address 172.16.0.2 in the
example should be replaced with your DNS server’s
external IP address. Following this, svscan
needs to be informed of the new service. This process accomplished
with three commands:

# ln -s /etc/tinydns /service
# svstat /service/tinydns

This will complete the installation of your djbdns server; all
that’s left is to do is configure your hosts. Under
BIND, this is where a majority of the complexity and confusion
exists; dbjdns, however, makes adding new DNS records much
easier.

Adding hosts

You will need to configure your host information so that your DNS server
is providing a service. The first step in this process is to
establish yourself as an authority over your domain. For our example,
a Virtual Brewery, we will want to configure our DNS server to
answer all queries for the vbrew.com domain. Rather than hassle with long zone files, this can be done with a few short steps.

# cd /service/tinydns/root
# ./add-ns vlager.com 172.16.1.1
# ./add-ns 1.16.172.in-addr.arpa 172.16.1.1
# make

Now that the server will handle queries for our vbrew domain, we can use it to configure
individual hosts on our network. Fortuantely, this is just as easy as
the previous step. To associate an address to our favorite host,
vlager, and to our Web server, we
need to use the following commands:

# cd /service/tinydns/root
# ./add-host vlager.vbrew.com 172.16.1.10
# ./add-host www.vlager.com 172.16.1.11
# ./add-alias mail.vbrew.com 172.16.1.10
# make

Using the add-host
command, we enter the FDQN followed by the IP addresss to create our
DNS records. You might have noticed the other command used in the
example, add-alias. This command adds an alias
to an already assigned IP. In the example, we have our host vlager set to also answer to the name
mail. This is useful if a server
serves multiple purposes. Take special notice of the last command
executed in the series, make. Things
won’t work if you forget to execute this command,
since it is responsible for compiling the raw configuration file,
into one readable by the server. If you’re having
problems with your installation, check this first.

The commands add-host, add-ns,
and add-alias just edit the master djbdns
configuration file called data located in
/service/tinydns/root. If you want to do this
manually, you can just open the datafile in your browser and add the
following lines:

     =vlager.vbrew.com:172.16.1.10
     =www.vlager.com:172.16.1.11
     +mail.vbrew.com:172.16.1.10

You’ll notice that the host
entry lines begin with = and the alias lines begin with a +
character. While the manual method does work, it adds more
complexity, since you will now be required to also manually check
your datafile for duplicate entries. Most administrators will just
want to stick with the automated tools to avoid complications.

Installing an external DNS cache

When you’ve successfully created your DNS server and
have everything functioning properly, you may want to create an
external DNS cache, so hosts on your network can resolve the IP
addresses of external machines. This is done by installing a DNS
cache, which again with djbdns is simple. Assuming that you have
svscan running, you must first create (or verify the
existance of) two system accounts, one for the cache program and one
for the logging mechanism. Though it isn’t necessary
to do so, it is a good idea to call them something meaningful, such
as dnscache and dnslog, respectively.

Next, you’ll need to
determine the IP address on which to run your DNS cache. Remember
this should be a different IP address than you’re
using for your DNS server. Now, as root, create a directory for the
DNS service and configure it with the following commands:

# mkdir /etc/dnscache
# dnscache-conf dnscache dnslog /etc/dnscache <cache.ip.address>

Again, as root, you now need to inform svscan that you have a new
service for it to run:

# ln -s /etc/dnscache /service

Now, to be certain that the new service is running, wait a few
moments and issue the following command:

# svstat /service/dnscache
/service/dnscache: up (pid 1139) 149 seconds

When you’ve made certain that the service is
running, you need to tell it which IP addresses are authorized to
access the cache. In the case of the Virtual Brewery, we want to
authorize the entire 172.16 network, so we’ll enter the following command:

# touch /etc/dnscache/root/ip/172.16

Of course, you’ll want to make sure that your
/etc/resolv.conf knows about your new DNS cache.
You can test to see whether or not your cache is working with
nslookup, dig, or one of the
included djbdns tools, dnsip:

# dnsip www.google.com
216.239.57.104 216.239.57.99
#