If you’re running BIND on Linux/UNIX for your DNS services, you’re likely familiar with the potential security implications. Although BIND is an excellent choice for many organizations, those looking for a DNS server with security included from the ground up might want to consider the djbdns package.
What is djbdns?
Djbdns is a true replacement for BIND, with none of the latter’s security baggage. In fact, the developer of djbdns, Dan Bernstein, offers a $500 reward for the first person who can legitimately compromise the product. Because djbdns was written with security in mind, he feels that his money is safe.
In addition to the focus on security, the product runs inside a chroot jail as a nonroot user. A chroot jail locks users into a specific directory structure without any access to files not explicitly allowed by the administrator.
Djbdns consists of a number of programs (listed in Table A) working in concert to provide DNS services. We’ll discuss some of these programs and utilities later in this article during a sample installation and configuration.
| Service | Description |
| Dnscache | Dnscache is a local DNS cache that accepts recursive DNS queries from local clients and collects responses from other DNS servers. |
| TinyDNS | TinyDNS is responsible for making DNS information available to the Internet. TinyDNS handles load balancing and client differentiation, or directing clients to specific servers. |
| Walldns | Walldns hides local host information from requested reverse and forward records. |
| Rbldns | Rbldns is an IP address-listing DNS service. It can be used to publish a list of IP addresses that provide a specific service. |
| Dnsfilter | Dnsfilter is an IP-address-to-hostname conversion utility. |
| dnsip, dnsipq, dnsname, dnstxt, dnsmx | These are command line tools used to manage the DNS services. |
| dnsq, dnsqr, dnstrace | These are DNS debugging utilities. |
How does djbdns stack up against BIND?
BIND has been around a long time, and it’s provided millions of users with the DNS services upon which the Internet runs. However, it has also been the subject of many major security bulletins and is a favored target among hackers.
In many ways, djbdns is an easier solution to administer than BIND, especially when you want to implement a highly secure installation. For example, by default, djbdns runs as a nonroot user in a jailed environment. To implement this under BIND, you must follow a number of additional steps. In addition, the configuration files necessary for making djbdns work are much simpler than those for BIND.
BIND follows the Internet Engineering Task Force standards more closely than the djbdns package does. For example, BIND supports the DNSSEC standard, while djbdns uses a more proprietary mechanism to protect the integrity of DNS data.
Meeting the requirements
Before you can install the DNS components of djbdns, you need to first install a couple of other packages (by same author), which the DNS server relies on to operate. The first one is daemontools and the second is ucspi-tcp.
The daemontools package consists of a number of tools used to manage UNIX services. For example, setuidgid runs another program under a specified account’s user ID and group ID. The ucspi-tcp package includes command line tools for building TCP client-server applications.
Installing the prerequisites
You can download daemontools from the daemontools installation page, and you can download ucspi-tcp here. I downloaded both of these packages as well as the djbdns package into my home directory at /home/slowe. If you are following along at home, be sure to change the directory reference to match your installation.
To install daemontools, follow these instructions:
- Create a directory named /package at the root level of your Linux server by issuing the command mkdir /package at a prompt.
- Change the permissions for security by typing chmod 1755 /package.
- Change to the package directory by typing cd /package.
- Expand the daemontools distribution by typing gunzip -c /home/slowe/daemontools-0.76.tar | tar xpfv -.
- Change to the distribution directory by typing cd /package/admin/daemontools-0.76.
- Compile and install the utilities by typing package/install and pressing [Enter]. You will see a bunch of compilation information scroll down the screen.
To install ucspi-tcp, follow these instructions:
- Change to the directory in which you downloaded ucspi-tcp. For me, the command is cd /home/slowe since the package is in my home directory.
- Expand the distribution with gunzip -dc ucspi-tcp-0.88.tar.gz | tar xvf –.
- Change to the expanded directory with cd ucspi-tcp-0.88.
- Compile the source code by typing make.
- Install the software by typing make setup check.
That’s all there is to it! Now it’s time to get to the meaty stuff.
Installing djbdns
Installing djbdns is easy, and the process is the same as for the ucspi-tcp package. I saved the distribution downloaded from the djbdns Web site to my home directory. I then executed the following commands:
- gunzip -dc djbdns-1.05.tar.gz | tar xvf –
- cd djbdns-1.05
- make
- make setup check
Djbdns is now ready to run with all of its components. Let’s take a look at how to configure it.
Configuring the software
After installing the software, you need to configure the various components to get a DNS server running. Note that I will be setting up only one simple DNS server in this article. For more complex installations and instructions for setting up a redundant DNS server, refer to the djbdns documentation.
Setting up the DNS cache
Use the following commands to create two UNIX users that will be used to run the services:
/usr/sbin/useradd -s /bin/false -c dnscache dnscache
/usr/sbin/useradd -s /bin/false -c dnslog dnslog
The -s /bin/false sets these accounts up so that they can’t log in. This helps to protect the security of the system.
The next step is to configure the cache so that it knows the IP address it should be using. The first IP address of my Linux server is 192.168.1.106. To configure the cache, I will use the following command for my installation:
dnscache-conf dnscache dnslog /etc/dnscache 192.168.1.106
The final step in setting up the DNS cache is starting the service. One of the utilities installed previously—svscan—will handle this after you give it the following command:
ln -s /etc/dnscache /service
After a few seconds, the service will start. You can verify that it has started by typing ps -ef | grep dns at the command line. For my installation, I get the following results:
root 4969 2776 0 15:05 ? 00:00:00 supervise dnscache
dnscache 4971 4969 0 15:05 ? 00:00:00 /usr/local/bin/dnscache
dnslog 4972 4970 0 15:05 ? 00:00:00 multilog t ./main
As you can see, the dnscache service is running as the dnscache user, while the logging component is running as the dnslog user. The dnscache service is now running and able to accept local requests.
Configuring and starting the TinyDNS component
For the TinyDNS component, an additional user named tinydns is required. Create that user with this command:
/usr/sbin/useradd -s /bin/false -c tinydns tinydns
Next, the TinyDNS configuration needs to be told on what IP address it should listen for requests. Note that this IP address cannot be the same one that the cache is listening on. So I have configured the network adapter on my Red Hat Linux 8 machine to have a second IP address of 192.168.1.217 and can configure TinyDNS with the following command:
tinydns-conf tinydns dnslog /etc/tinydns 192.168.1.217
Like the cache, the TinyDNS daemon can be started by putting it in a place where svscan will find it:
ln -s /etc/tinydns /service
Using ps -ef | grep dns, I can make sure that TinyDNS has started. I get the following results:
root 5177 2776 0 15:27 ? 00:00:00 supervise tinydns
tinydns 5179 5177 0 15:27 ? 00:00:00 /usr/local/bin/tinydns
dnslog 5180 5178 0 15:27 ? 00:00:00 multilog t ./main
The next step in the process is to give TinyDNS something to do by providing it with a list of hosts to work with. This information is defined in /etc/tinydns/root/data and can be modified with a text editor. I like to use pico. In my configuration file, I have place the following sample data:
#define the authoritative nameserver
.slowe.com::ns1.slowe.com
#mail exchanger
@slowe.com::mail.slowe.com
#IP addresses for hosts
=host1.slowe.com:192.168.1.101
=host2.slowe.com:192.168.1.112
=rh8.slowe.com:192.168.1.217
#rh8 is also known as ns1
+ns1.slowe.com:192.168.1.217
#machine1 is our mailserver
+mail.slowe.com:192.168.1.101
#and our webserver
+www.slowe.com:192.168.1.112
Once this information is in the configuration file, you can compile it by typing make in the /etc/tinydns/root directory, which will create a file named data.cdb that TinyDNS will read.
Testing it
Testing this is simple. Go to another machine, look up a name that was entered into the data file, and see if an IP address comes back. I happen to have a Windows XP machine on the same network and can use nslookup as a test. For example:
C:\>nslookup www.slowe.com 192.168.1.217
Server: rh8.slowe.com
Address: 192.168.1.217
Name: www.slowe.com
Address: 192.168.1.112
As you can see, an IP address was resolved correctly, which shows that the DNS service is working.
Summary
Getting the components of djbdns set up and running for a simple configuration is not really a lot of work. However, to support more complex configurations, some work and research will be required. The documentation on the djbdns Web site is a great place to start.
Daily Tech Insider Newsletter
Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game.
Delivered Weekdays
