You’ve set up some servers (mail, web, FTP) that need to be accessible to the outside world. They need domain names, like www.oreilly.com, since you don’t want people using IP addresses. You want to run your own DNS server to provide those names. You tried BIND, and it was just too complicated. Or you heard some scary talk about BIND security problems. Whatever the reason, you’ve decided to use djbdns. So how do you make it go?

First, follow the preparatory steps in to run a public DNS server. Then follow these steps to install and set up tinydns, which is the authoritative DNS server component of djbdns. If you are also running dnscache, it must not have the same IP address as tinydns. This is a very important security measure. Both dnscache and tinydns will fail silently if you do it anyway.

Follow these steps in for djbdns installation. Then, create two system users, using any names you like. They will own the tinydns server, and the dnslog:

# useradd -d /dev/null -s /bin/false tinydns

# useradd -d /dev/null -s /bin/false dnslog

Run tinydns-conf to create directories and set the IP address of the tinydns server. List your system users in the order shown here:

# tinydns-conf tinydns dnslog /etc/tinydns 208.201.239.36

Create a startup entry in service:

# ln -s /etc/tinydns /service

Wait a few seconds, then run svstat to verify that it started:

# svstat /service/tinydns /service/tinydns: up (pid 6811) 14 seconds

If tinydns won’t stay up continuously, check the logfile in /etc/tinydns/log/main/current. That will tell you where the problem is.

Now it’s time to create your host entries. This shows how to create entries using the scripts that come with tinydns. In this example the domain name is pixels.net, which is duly registered with a domain name registrar.

Create the host entries as follows:

# cd /service/tinydns/root

# ./add-ns pixels.net 208.201.239.36

# ./add-ns .239.201.208.in-addr.arpa 208.201.239.36

# ./add-host parsley.pixels.net 208.201.239.36

# ./add-host sage.pixels.net 208.201.239.37

# ./add-host rosemary.pixels.net 208.201.239.38

# ./add-alias ftp.pixels.net 208.201.239.37

# ./add-alias www.pixels.net 208.201.239.38

# make

That’s all it takes to build a tinydns server.

The previous commands inserted data into /etc/tinydns/root/data; here’s what it looks like:

.pixels.net:208.201.239.36:a:259200

.239.201.208.in-addr.arpa:208.201.239.36:a:259200

=parsley.pixels.net:208.201.239.36:86400

=sage.pixels.net:208.201.239.37:86400

=rosemary.pixels.net:208.201.239.38:86400

+ftp.pixels.net:208.201.239.37:86400

+www.pixels.net:208.201.239.38:86400

You typically configure djbdns by running configuration scripts, not by editing the data file by hand. Here are the available configuration scripts:

add-host

Creates both an A (alias) record and a PTR (reverse pointer)

add-mx

Adds a mail server

add-ns

Adds a name server

add-alias

Creates an A record but not a matching PTR

add-childns

Adds a child name server—use this when you want to act like an ISP and host other name servers

Here is a list of the leading symbols used by tinydns:

. (leading dot)

Name server

=

Both pointer (PTR) and A record

+

A record

&

NS and A records

@

MX and A records

As you can see, tinydns thoughtfully calculates the time-to-live (TTL) values for you. The TTL tells caching servers, in seconds, how often they should come back to refresh their information. tinydns will continue to adjust these automatically; don’t worry about tweaking them manually.

You can edit the djbdns data file manually, if you want. You can add comments, change the order of the entries, whatever you like. The scripts are for convenience, and to ensure that each entry is in the correct format. Just remember to run make every time you make a change, to convert the file to /etc/tinydns/root/data.cdb.

The clear separation of functions is one of the strengths of djbdns. You do not want your caching server anywhere near your authoritative DNS server. In other words, the IP addresses listed in /etc/resolv.conf should never match any IP addresses listed in NS records. If your caching server is compromised and is running on the same IP address as your DNS server, the attacker could misdirect all of your traffic, including "secure" web applications.

Your caching server is ready to go to work—how you do tell your Linux and Windows clients how to find it?

If your clients are served by DHCP, you need to edit your DHCP configuration file to point to your new name server.

Linux hosts with static IP addresses that are not served by DHCP configure their name servers in /etc/resolv.conf. In this example, your name server is at 192.168.1.200, so all you do is edit /etc/resolv.conf:

nameserver 192.168.1.200

The resolver queries the entries in order, so make this the first one if you have others. Typically, your ISP will list a primary and a secondary name server in your account information, so you can list these next:

nameserver 192.168.1.200

nameserver 12.188.166.2

nameserver 12.188.166.3

On Windows hosts with static IP addresses, find the menu for configuring Internet Protocol (TCP/IP) properties. In Windows 95/98/ME, go to Control Panel -> Network -> TCP/IP -> Properties. Go to the DNS Configuration tab, and there you are.

In Windows NT/2000/XP, go to Control Panel -> Network Connections. Right-click Local Area Connection, then select Internet Protocol (TCP/IP) -> Properties.

That’s pretty much all you have to do; a DNS cache is low-maintenance. You may enter up to three name servers on client machines.

Make sure you do not give the entire Internet access to your caching server! This is a big security hole; plus, there’s no reason for you to provide caching for the masses.

Windows 2000/XP comes with its own built-in DNS cache. You didn’t know it was there, did you. You can view the contents of the cache with this command:

C:\> ipconfig /displaydns

To flush the cache, use:

C:\> ipconfig /flushdns

Flushing the cache is a quick way to get rid of stale data, such as when you change a server’s IP address.

You want to set up a local djbdns caching name server just to serve your LAN. This will speed up DNS lookups, which in turn will speed up web surfing, email, and all Internet services.

The caching component of djbdns is dnscache. First, prepare your system by installing daemontools, uspci-tcp, and djbdns

After installing everything, run a dnsip query to confirm that djbdns installed correctly:

$ dnsip www.oreillynet.com

208.201.239.37 208.201.239.36

Now create two system users to own dnscache and dnslog. Call them anything you want. In this example, they are simply "dnscache" and "dnslog":

# useradd -d /dev/null -s /bin/false dnscache

# useradd -d /dev/null -s /bin/false dnslog

Then configure the IP address and service directory for dnscache. This also assigns the appropriate file ownerships:

# dnscache-conf dnscache dnslog /etc/dnscache 192.168.1.5

Create your "allow" list; this example permits your local subnet to use your dnscache:

# touch /etc/dnscache/root/ip/192.168.1

Now start it up:

# ln -s /etc/dnscache /service

To verify that it’s running, use svstat:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 30 seconds

To verify that it’s working, run dnsqr to query the local cache:

# env DNSCACHEIP=192.168.1.5 dnsqr a www.yahoo.com

1 www.yahoo.com:

193 bytes, 1+9+0+0 records, response, noerror

query: 1 www.yahoo.com

answer: www.yahoo.com 286 CNAME www.yahoo.akadns.net

answer: www.yahoo.akadns.net 60 A 66.94.230.52

answer: www.yahoo.akadns.net 60 A 66.94.230.48

Configure clients to point to your dnscache server, and you’re finished.

A caching server, or caching DNS resolver, does two things: it answers DNS requests by getting the information from other servers, and then it stores the results so that it can answer future requests for the same information directly. The cache lives only in memory, so restarting the cache’s process or rebooting wipes it all out.

A caching server and an authoritative DNS server should always be strictly separated. This means the IP address of your caching server should never match any IP addresses listed in NS records. A few bad things can happen when you put them together:

• If an attacker seizes control of your DNS cache, the attacker can control not only your incoming DNS data, but also your outgoing DNS data—which means he can hijack your web sites, email, FTP, and any "secure" web-based applications.
• If your DNS cache suffers a Distributed Denial of Service (DDoS) attack, your authoritative server will also be pummeled, and you will have no DNS service.

RFC 2010 also advises keeping caching servers separate from authoritative servers:

Recursion is a major source of cache pollution, and can be a major drain on name server performance. An organization’s recursive DNS needs should be served by some other host than its root name server(s).

With BIND, you cannot separate the two. But you can with djbdns.

When you’re testing dnscache, and making changes and generally futzing around, sometimes you’ll find it won’t stay up:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 1 seconds

# svstat /service/dnscache

/service/dnscache: up (pid 6781) 0 seconds

You probably have too many instances of it running. Try this:

# netstat -nap | grep ":53"

tcp  0  0 127.0.0.1:53    0.0.0.0:*    LISTEN     6327/dnscache

tcp  0  0 192.168.1.5:53  0.0.0.0:*    LISTEN     6129/dnscache

udp  0  0 127.0.0.1:53    0.0.0.0:*               6327/dnscache

udp  0  0 192.168.1.5:53  0.0.0.0:*               6129/dnscache

Yep, that’s too many. You should have two instances only: listening on TCP port 53 and UDP port 53. Do a killall supervise dnscache, give it a few seconds, then try again:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 21 seconds

# netstat -nap | grep ":53"

tcp  0  0 192.168.1.5:53   0.0.0.0:*   LISTEN     6776/dnscache

udp  0  0 192.168.1.5:53   0.0.0.0:*              6776/dnscache

That’s what you want to see.

Another common problem is having an old BIND server still running. There Can Be Only One.

djbdns comes with a number of network querying and diagnostic utilities: dnsqr, dnstrace, dnsip, tinydns-get, dnsipq, dnsmx, and dnsname. See the links below to learn more about them.

By default, tinydns-conf and dnscache-conf put the logfiles in /etc/tinydns/log/main and /etc/dnscache/log/main, which are not the usual places for logfiles. You would rather move them to /var/log, where they belong.

To put the logfiles for tinydns in /var/log/tinydns, edit /etc/tinydns/log/run, as follows:

#!/bin/sh

exec setuidgid dnslog multilog t /var/log/tinydns

Do the same for dnscache, editing /etc/dnscache/log/run, as follows:

#!/bin/sh

exec setuidgid dnslog multilog t /var/log/dnscache

You need three source tarballs: daemontools, uscpi-tcp, and djbdns. Get these from the djbdns home page at http://cr.yp.to/djbdns.html.

After installation, you’re ready to start configuration.

To install daemontools, follow these steps:

# mkdir -m 1755 /package

# cd /package

Download and unpack the latest daemontools tarball into /package, as follows:

# tar xzvpf daemontools-0.76.tar.gz

# cd admin/daemontools-0.76

To compile and set up the daemontools programs, use:

# package/install

Next, fetch the latest uspci-tcp tarball and install it:

# cd /usr/sources

# tar xzvf ucspi-tcp-0.88.tar

# cd ucspi-tcp-0.88

# make

# make setup check

It puts itself into /usr/local/bin.

Finally, fetch and install djbdns:

# tar xzvf djbdns-1.05.tar.gz

# cd  djbdns-1.05

# make

# make setup check

It puts itself into /usr/local/bin.

daemontools is a suite of utilities for managing services. You’ll see supervise, multilog, and svstat. supervise automatically restarts services if they die unexpectedly. multilog is a nice log manager that automatically rotates log data, so that logs don’t consume your disk space and you always have fresh data. svstat tells you the status of a service.

uspci-tcp takes the place of inetd and xinetd, for running djbdns and other Dan Bernstein programs. You don’t have to do anything other than install it.

djbdns is a suite of DNS programs.