Running a Local Caching Name Server with djbdns

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

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

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= dnsqr a


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

query: 1

answer: 286 CNAME

answer: 60 A

answer: 60 A

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* LISTEN 6327/dnscache

tcp 0 0* LISTEN 6129/dnscache

udp 0 0* 6327/dnscache

udp 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* LISTEN 6776/dnscache

udp 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.