Due to the recent, highly publicized Lion worm running rampant on the Internet, exploiting publicly known vulnerabilities in older versions of BIND, you may be considering moving your own systems to djbdns. In fact, the only 8.x series version of BIND that doesn’t contain these vulnerabilities is the very last version, 8.2.3. So if you haven't upgraded BIND yet, you might want to make sure that you have not been infected by the Lion worm. You can do so by visiting the SANS Web site to read the advisory and to download a program to detect whether or not the t0rn rootkit, which the worm installs on infected systems, is on your system.
In the first part of this series, I looked at downloading, compiling, and installing djbdns, which is an alternate DNS server designed to be secure. Like Qmail, a secure e-mail server written by the same author, djbdns breaks down a complex server into smaller components that work together to perform a task. By breaking the server into several smaller components, the risk of compromise is severely limited because if one part of the server is compromised, the entire server or system is not affected, just the one piece.
If you followed the previous article in this series, “Getting rid of BIND (Buggy, er, Berkeley Internet Name Daemon),” you will have djbdns installed and almost ready to go. The final step is to take your data from your existing BIND server and import it into djbdns. Then, you can safely remove BIND, start djbdns, and still provide the service with confidence.
Obtaining the data from BIND
Security implications (or the lack thereof) aside, if you currently use or have used BIND, you are accustomed to two primary configuration files that load your zone files. The /etc/named.conf and /etc/named.boot files tell BIND what zones to load, and the zone files themselves are typically stored in /var/named as one file per zone.
There is one major difference between djbdns and BIND: djbdns does things a little differently. Inside of using one file per zone, djbdns stores everything in one large hashed database. The /etc/tinydns/root/data file is a human-readable and editable file that contains information for all of the zones you manage. Using the standard UNIX make command, you compile this file into a hashed database stored in the file /etc/tinydns/root/data.cdb. This is the file that tinydns, the part of the server that responds to DNS queries, reads to obtain information on the zones you control.
Consequently, this is the file that is sent to other secondary DNS servers for use. Unlike BIND, you cannot have one secondary for a few zones and exclude others. If you have a secondary djbdns, it will be a secondary server for all zones that are controlled by the primary server. This is perhaps the only drawback in using djbdns.
Incidentally, this is an intentional feature in djbdns. This is because of the philosophy the author holds regarding third-party off-site DNS servers, which I will explain in a moment. The first thing we want to do right now is get your data out of BIND and into djbdns.
Let's assume that you operate the domain mydomain.com, and you currently have an existing BIND server that manages that domain. You can use the tcpclient program included with djbdns to obtain a zone transfer for that domain and store it in a format that djbdns understands by using this command.
This command will retrieve the zone information for mydomain.com from the server dns1.mydomain.com (which we will assume is the same system on which you are setting up djbdns). The tcpclient opens a connection to dns1.mydomain.com on port 53, the standard port that DNS servers listen to, and then the axfr-get program retrieves the zone information for mydomain.com. The final destination file will be zone-mydomain.com, and the temporary file to use is zone-mydomain.com.tmp.
Do this with each zone you control, including your reverse DNS zone and the in-addr.arpa zone for your IP addresses. For instance, if dns1.mydomain.com is using the IP address 220.127.116.11, you may have an in-addr.arpa file for the 212.58.32.* IP address range, which would be written as 32.58.212.in-addr.arpa. In that case, you would use this command.
Once you have retrieved all of the zone files for each zone you control, you must merge the zone files into a single file, data, and compile the hashed database, data.cdb. The recommended method to do this is to execute:
sort -u zone* >data
This will sort all of the entries in each zone file and write them to the file data. The make command will compile the hashed database for you. You can then check your settings to make sure that djbdns returns the same information that BIND would. To do so, use the tinydns-get program to see what information tinydns will return for a hostname and then use the dnsq command to see what BIND will return for the same hostname, like so:
tinydns-get a www.mydomain.com
dnsq a www.mydomain.com dns1.mydomain.com
The information returned should be identical. If it is, you can safely kill the BIND process on your system and start djbdns. On most Linux systems, you will be able to kill BIND by issuing:
At this point, you would link the /etc/tinydns and /etc/axfrdns directories under the /service directory you created in the last part of this series by using:
ln -s /etc/tinydns /service
ln -s /etc/axfrdns /service
Roughly five seconds later, djbdns will start and begin handling the queries on your system that BIND once handled.
Using multiple zone files BIND-style
If you come from a background of having used BIND, you probably really dislike the idea of making changes for a zone in one big file that handles all zones. Fortunately, there is a way you can retain your old style of using one file per zone.
When you originally transferred your data from BIND, you stored the zone information in separate files. If you look at your /etc/tinydns/root directory, you will probably see a few files that begin with zone. Instead of removing these files after creating your initial data file, you can keep them and make your changes to those files specifically.
When you make changes to a zone file, you will need to re-sort all of the zone files and redirect the output to data, just as you did before. Then, you can run make to build the hashed database. To make it even easier, you can modify the /etc/tinydns/root/Makefile file to add another command to it. Edit your Makefile to look something like this example.
The last two lines should be new to your Makefile. Only make this change on your primary DNS server. Remember, you are transferring the data.cdb file from the primary to the secondary djbdns server, so you should never be running make on the secondary server.
Now you can edit your zone files and when you have made the changes you want to make, you can simply issue:
and the hashed database will be created for you by automatically sorting your zone files and creating the data file.
Do you need third-party servers?
One question you may have never asked yourself is whether or not you actually need those third-party servers you may be paying for. There are a few arguments about whether or not you need them, which is perhaps one reason why djbdns was designed the way it is. The author's arguments against third-party servers is available on the djbdns site. What he says makes very good sense, if you only maintain zone files for your own domains and they are only for your machines.
If your entire network goes down, there really is no need for a third-party DNS server. Hostnames that are being resolved won't be available anyway due to the fact that the entire network is down. This makes sense. Some people may not realize this and might be paying for a service they don't really need.
However, if you provide DNS services for systems that are not on your network, then this is not the case at all. If, for example, you provide domain-hosting solutions and one of those solutions is DNS information, you may be providing DNS information for a domain that is not associated with your network or servers at all. All of the systems in the domain you are hosting may be located on another system or multiple systems nowhere near your own system. In this case, if your network or DNS servers are unavailable, lookups to a system that most likely is up and ready will fail, and the servers you are providing DNS information for will be unreachable.
In this respect, having a third-party backup DNS server may be beneficial. If your network goes down, it doesn't necessarily mean that your customers will be unreachable on their systems. Of course, in order for this to be effective, your customers must know about the third-party server and include it in the authoritative list of DNS servers for their domains.
Unfortunately, djbdns doesn't play very nice with BIND in such a case. When it comes to selective zone transfers, djbdns cannot do the job easily and will require a bit of a hack. You can easily use a cron job to schedule automatic zone transfers from another server if you are the third-party server and write it to a zone file, which in turn will be built into the hashed database if an update is required. That isn't too terribly difficult; I've already illustrated and used the commands to obtain the zone information. Work a little cron magic, and this is no longer an obstacle.
The reverse, however, should be no problem. BIND performs zone transfers internally, which has been a source of problems for the software in the past. There should be no problem having a BIND server obtain zone transfers from a djbdns server, so if your secondary or third-party DNS server is using BIND, you do not need to worry about compatibility issues.
Understanding the data file
The format of the data file is very different from the zone files used by BIND and, as such, require a little explaining. Like the BIND zone files, there is one entry per line in the data file that provides instruction for the zone or a particular hostname or IP in that zone. Let's take a look at the commonly used BIND configuration entries and their djbdns counterparts.
For the domain mydomain.com, you might have used this code as a zone file in BIND.
To accomplish the same thing with djbdns, you would insert this code into a zone file, if you are going to use separate zone files, or directly into the data file.
As you can see, the layout is completely different. Let's take a look at the particulars. In BIND, the SOA is defined by the phrase IN SOA, but in djbdns, it is the line prefixed with the Z character. It also contains all of the same information: the administrator e-mail address and all the values for the serial, refresh time, retry time, expire time, and default time-to-live.
The NS records in BIND are noted in djbdns with a line prefixed with the ampersand (&) character. Likewise, the MX records in BIND are noted in djbdns with a line prefixed with the at (@) character. A records in BIND are noted as such with the plus (+) character in djbdns, and CNAME records in BIND are noted as such with the C character in djbdns. You can also see that each entry has its own default time-to-live specification at the end of each line, including the SOA record.
For a more detailed explanation of the tinydns data layout, visit the tinydns site. Of course, there are a few programs in the /etc/tinydns/root directory that will assist you in adding new records to your data file. The add-alias program will add a new CNAME record, the add-host program adds a new A record, the add-mx program adds a new MX record, and the add-ns program adds a new NS record to the zone specified on the command line. The only caveat is that these programs will directly modify the data file, not your separate zone files if you use that system. Likewise, it will not help you to remove records from a domain; programs are available only to add new records.
Keep in mind that there are more alternatives to BIND than just djbdns. The reason I have selected djbdns as a replacement server for my own systems is its track record is not speckled with security problems and because it was written by the same author who wrote Qmail—a mail server that is unquestionably secure and reliable. Since djbdns follows the same model, it seemed the perfect solution to the security issues that have plagued myself and many other system administrators, especially in the last few months. BIND is a program historically known for security problems and more recently known for the propagation of a particularly devastating worm. To put it simply, BIND needs to be replaced. If djbdns is not the obvious or best choice, then I sincerely hope that someone comes up with something better, because—at least for this system administrator—BIND is no longer an option.
However, when you look at all of this, don't necessarily think that ease of use should be the end result. Realistically, you won't be changing your DNS information very often. As long as you keep some reference material and the Web site URL handy, you should be able to figure everything out. The trade-off, however, is the removal of BIND from your system. This alone should make up for any pains in upgrading to djbdns.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.