Kiss Your BIND Good-bye: In-Depth Configuration with Tinydns

by Carla Schroder

Tinydns is a scalable and secure BIND replacement for everything from home user DNS caching to large-scale enterprise networks. In Part 2 of our look at Tinydns, Carla Schroder goes in-depth on configuration.

Last week we looked at the broad strokes of Tinydns, a replacement for BIND you can drop into anything from a home LAN to an enterprise deployment. This week it's time to get in-depth with configuration, so let's start off with some clarification of terminology. DNS is confusing enough, and BIND is the Lord of Vague Concepts. Simply resolving names to IP addresses shouldn't be complicated and weird, but it is.

Recursive: this is a word that UNIX gurus use and abuse to death. All it means is "you do whatever it takes to answer this question." A recursive DNS query means the program doing the query keeps churning until an authoritative answer is found. Aha! you say, a light dawning. That is why tinydns does not support recursion- to close off one popular avenue for Denial of Service attacks. dnscache handles recursive requests, that is why it is hidden away inside the private network.

Iterative: pass the buck. tinydns supports iterative queries- it hands off the query to other servers and forgets about it until someone sends back an answer. Same as 'non-recursive'.

Resolver: the program on the client that resolves names to addresses. You've probably configured this without realizing it is called 'resolver.' This is where you set the DNS servers and the search order on the client machine- on Windows, it's the 'DNS Configuration' tab in the TCP/IP control panel. In Linux, it's /etc/resolv.conf.

As you have faithfully read and memorized all of my columns, you will have already done part 1, and installed daemontools and djbdns. Skip anything about afxr. afxr is reluctantly included for zone transfers, DJ Bernstein recommends using rsync instead. afxr uses DNS-over-TCP, which DJB does not like, both for speed and security reasons.

All right, now we have fun. It is a good idea to draw up a network map first: hostnames, nameservers, IP addresses, DHCP ranges, web and mail servers, domain name. Our sample domain is www.guru.com. There are all kinds of ways to organize your data, tables and flow charts are fun and easy to read.

static, routable IP
assigned by ISP

Our setup is an Internet account with a static IP, and a firewall doing NAT (network address translation). To run your own nameserver, it must be officially registered. Your domain name registrar ought to provide this service. In this example, I would register ns1.guru.com with my static, routable IP address: This will point all Internet queries for your domain name to your static IP. Your firewall must then direct traffic to the appropriate server inside your network. This simplifies network management, you can move servers around and change IPs without having the 24-72 hour DNS propagation delay.

Another option is to run certain servers outside the NAT firewall, perhaps a Web server. This is perilous, make sure it is tightly locked down. It will require a static, routable IP of its own.

Caching In
On a small network, every PC can have its own cache. It's free and easy. Create two user accounts, dnscache and dnslog. Make sure they cannot log in (/sbin/nologin). Run dnscache-conf to create the service directory:

$ dnscache-conf dnscache dnslog /etc/dnscache

Tell svscan about the new service:

$ ln -s /etc/dnscache /service

Edit /etc/resolv.conf:


To create an external cache on the local network: In this example the external cache is on bigserver1. Run dnscache-conf to create the service directory, with your server IP address at the end of the line:

# dnscache-conf dnscache dnslog /etc/dnscachex

Tell svscan about the new service:

# ln -s /etc/dnscachex /service

Because dnscache by default does not accept queries from remote hosts, this must be enabled:

# touch /etc/dnscachex/root/ip/192.168.1

to accept queries from 192.168.1*

The client machines' resolvers must point to

For security, do not put dnscache on the same IP address as the name server. In Linux it easy to assign multiple IPs to the same NIC, using ifconfig:

# /sbin/ifconfig eth0:0 address

etho0 is the first NIC on your system, eth0:0 is the first alias, eth0:1 is the second, and so forth. A non-routable IP, such as the example above, is good, remember the cache should not be visible to the outside world.

DNS Itself
Create a tinydns user account, with no login privileges. Run tiny-dns.conf:

$ tinydns-conf tinydns dnslog /etc/tinydns

Tell svscan:

$ ln -s /etc/tinydns /service

There are two ways to configure tinydns. One is to use DJB's scripts, such as add-ns, add-mx, and add-host, the other is open the tinydns configuration file, /etc/tinydns/root, and edit it directly. I like to edit /etc/tinydns/root directly, so I can organize and comment it to suit my needs. The scripts have error-checking and automatically write the correct syntax. A good learning tool is to generate a config file with scripts, then study it. Notice the different prefixes for the different types of servers. tinydns uses letter suffixes- a, b, c, etc., to indicate mailserver precedence.

#name of authoritative nameserver
#mail exchangers

Remember, the only computers listed here are the ones that need to be visible by name to the outside world. Doubtless you alert readers have noticed there is no TTL (time to live) specified. tinydns contains default values, you may also specify your own:


There is no SOA (start of authority) line, either. Again, tinydns makes one for you, or specify your own:


The final step is cd to /etc/tinydns/root, and run make. This converts the text file to csb (constant database) format. That's all there is to it.

This is a very simple setup. djbdns will do zone transfers, reverse DNS, parents and delegations, and load balancing, pretty much anything you need. For way big networks, it supports using mySQL, LDAP, and other backends. If you're an experienced BIND admin, you may think it is lacking a function you want, when it actually does it in a different way.

djbdns Quirks
tinydns likes to use its own server prefixes: a.ns, b.ns, and so forth, rather than ns1, ns2. This is not an industry standard, and will not work on all domain name registrars. Use either one as it suits you. It has its own ideas about where its files should be installed, I have not tried moving them to see if that breaks anything. As long as it works well and does what I want, I'm not going to crab about file locations.

Life With djbdns

» See All Articles by Columnist Carla Shroder

This article was originally published on Wednesday Aug 21st 2002