djbdns: More Than Just a Mouthful of Consonants
The latest version of djbdns compiles on all the major Linux distributions. You also need to install daemontools (see sidebar), another package by Dan Bernstein.
daemontools is a collection of tools for managing UNIX services. Like most of Dan Bernstein's software, djbdns relies on daemontools.
daemontools services are created in directories, and they must contain an executable script named run. To start a service, you simply create a symbolic link from that directory into /service. Within five seconds, the svscan process will notice the new service, start it and begin monitoring it.
Logging is handled by the multilog program from the daemontools package. Anything written to standard output by the program is recorded in the processes log file, named current. Typically, the logs are stored within the service directory. For example, dnscache's logs would be in /service/dnscache/log/main/current. multilog automatically rotates the current file once it reaches a certain size.
These days, I prefer the Ubuntu server distribution, which recently introduced the upstart replacement for init. I've written a patch for daemontools to make it compatible with upstart. See dnsfool.com/tips for the patch. daemontools is available from cr.yp.to/daemontools.html.
Download djbdns from Bernstein's Web site, and run the following commands. The third line is a workaround for a glibc bug on Linux:
# tar xzf djbdns-1.05.tar.gz # cd djbdns-1.05 # echo gcc -O2 -include /usr/include/errno.h > conf-cc # make # make setup check
See Bernstein's official documentation if you have further questions about installing djbdns.
One of the easiest ways to begin using djbdns is to configure a DNS cache on your local network. There are many reasons why you may want to do this—from faster DNS lookup times to avoiding those pesky mistyped domain search result pages. In either case, installing dnscache can help.
Let's assume you have a home network with several computers on 192.168.10.0/24. Additionally, a Linux machine (named linux1) is running on 192.168.10.10. You want to install dnscache on linux1, so it can provide DNS resolution service for the other machines on the network.
Fortunately, installing dnscache is trivial, thanks to the dnscache-conf utility provided with djbdns. Before running dnscache-conf, you need to create one new group and two accounts on linux1. These will be used exclusively by djbdns and should not be available for login:
# groupadd djbdns # useradd -s /bin/false -d /etc/dnscache -g djbdns dnscache # useradd -s /bin/false -d /dev/null -g djbdns dnslog
The next step is to run dnscache-conf and provide it with four parameters: the account for the dnscache process, the account for the logging process, the dnscache service directory and the IP on which dnscache should listen:
# dnscache-conf dnscache dnslog /etc/dnscache 192.168.10.10
The /etc/dnscache directory now should exist. Before you can begin using your new cache, you need to allow access to it from your local network. dnscache checks to see if a machine is allowed to access it by comparing the IP of the incoming request address against files in /etc/dnscache/root/ip/. You can grant access to your whole network simply by touching a single file:
# touch /etc/dnscache/root/ip/192.168.10
At this point, you are ready to start the cache. If you are running BIND, you need to stop and disable it so that dnscache can take ownership of port 53. Assuming daemontools is installed and running, you now can start dnscache:
# ln -s /etc/dnscache /service/
That's it. You now have a DNS cache running on your local network. Your next step is to update the /etc/resolv.conf file on all your machines to point to 192.168.10.10:
If your network is very busy, you may find you need to increase the amount of memory that is allocated to your cache. Dan Bernstein provides instructions on his Web site for adjusting the cache size, but you also may want to take a look at Paul Jarc's cache-effect.pl Perl script or Mike Babcock's dnscacheproc.py Python script.
If you have ever run BIND as an authoritative DNS server, it is likely that at some point you neglected to increment the serial on an SOA record, overlooked a missing semicolon somewhere or simply forgot to append a period (.) at the end of a record. These are just a few of the common mistakes people make when dealing with BIND's zone files. If you have been bitten by any of these issues, you probably remember the trouble it created for you. These errors can cause big headaches (just ask Google).
tinydns, the authoritative DNS server in djbdns, takes an entirely different approach and makes it much more difficult to get yourself in trouble. One major difference is that instead of separate zone files for each domain, tinydns uses a single text file named data to store every record of every domain. This data file is then compiled into a very fast database in cdb format. Of course, if you prefer managing domains in separate files, you still can, just concatenate them together before compiling the database.
Let's get started by configuring our tinydns instance. You should have daemontools already installed and running. Again, let's assume we are running a home network on 192.168.10.0/24, and we now want to access each host by name using DNS. We have another Linux machine (named linux2) running on 192.168.10.20 that will publish DNS information with tinydns.
First, create the tinydns user:
# useradd -s /bin/false -d /etc/tinydns -g djbdns tinydns
Like dnscache, there is a utility for creating and configuring instances of tinydns. It also takes four parameters: the account for the tinydns process, the account for the logging process, the tinydns service directory and the IP on which tinydns should listen:
# tinydns-conf tinydns dnslog /etc/tinydns 192.168.10.20
This creates the /etc/tinydns directory and populates it with everything needed to begin publishing your DNS data. The last step is to create a symbolic link for the tinydns service into /service. Again, be sure to stop and disable any BIND instances first:
# ln -s /etc/tinydns/ /service/
Now you can begin adding records for each host on your network.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Favorite (and easily brute-forced) pw's
5 min 56 sec ago
- Have you tried Boxen? It's a
5 hours 57 min ago
- seo services in india
10 hours 29 min ago
- For KDE install kio-mtp
10 hours 30 min ago
- Evernote is much more...
12 hours 30 min ago
- Reply to comment | Linux Journal
21 hours 15 min ago
- Dynamic DNS
21 hours 49 min ago
- Reply to comment | Linux Journal
22 hours 48 min ago
- Reply to comment | Linux Journal
23 hours 38 min ago
- Not free anymore
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?