5.6. Operating djbdns

There are two different functions you will most likely use in the djbdns suite. On a given machine, you will either run dnscache to act as a caching server, or you will run tinydns to be an authoritative server. If you use jails, you may run them both on the same system, but with different IP addresses. The operation of both services is largely the same. Most of this section discusses running tinydns, because it requires the most careful configuration and the most frequent updates to its configuration.

Generally speaking, once dnscache is configured correctly, it runs without much maintenance or change. This is one of the key advantages of djbdns' separation of duties. It mandates that the DNS cache for the organization must be independent of the authoritative server. The caching server, then, can be set up once and largely left alone while it does its job.

5.6.1. Running tinydns

The tinydns installation sets up its own chroot environment by default. It runs in that environment and setuid to a nonprivileged user by default. Assuming your tinydns configuration is located in /etc/tinydns as the instructions suggest, then you will have a directory called /etc/tinydns/root where all the DNS zone information lives. There is a file there named data that contains, in text form, all the zone information. There is also a Makefile that contains rules for turning the data file into the data.cdb file. The data.cdb file is an optimized binary file that is actually used by tinydns to serve the zone data.

5.6.2. Routine Maintenance

There are a number of common maintenance tasks with tinydns whose execution varies based on your individual environment. You often will have to manually manipulate the data file, which contains the source data for all your zones.

5.6.2.1 The tinydns data file

While it is true that some tasks are automated by the various add-* scripts, many tasks are not. It is highly likely that you will need to edit the data file from time to time to do all the things in your zone that you need to do. This file is primarily intended to be produced and parsed by programs, but it is straightforward enough that a human can read and manipulate it.

The data file represents zone records by listing them one per line. The first character indicates what kind of record is being created, and the remainder of the line is a series of colon-separated fields describing the record. Note well that, unlike a BIND zone file, a single line of a tinydns data file often expands into many DNS records, sometimes in multiple zones. The lines that create A records, for instance, can automatically create the corresponding reverse PTR records in the appropriate in-addr.arpa zone.

The following summary describes the lines that you might put in a tinydns data file.

.

(period)

This record sets a nameserver for the given domain. The domain is considered to be this domain, as opposed to a domain that we are delegating. The tinydns server will automatically generate a start of authority (SOA) record for this entry. In this example, the domain is example.com and the server that serves it is ns.exampleisp.com:

.example.com:12.34.56.78:ns.exampleisp.com

Note that all the fields that are part of an SOA record (such as the TTL, expiration time, refresh time and hostmaster email address), and all the nameserver entries are automatically filled in with default values. If you want to have control over the fields in the SOA record, you will have to look up the Z record in the djbdns documentation.

& (ampersand)

This record is a delegation to another name server. It creates an NS record and corresponding A records (if they fall within the tinydns server's ken), but does not create an SOA record. For example:

&lab.example.com:12.34.60.4:ns.lab.example.com

= (equals)

This entry creates a normal A record and corresponding reverse PTR record. The PTR record is of no use unless the reverse zone is delegated to your server. If it is, however, you do not need to do anything extra. The reverse records are always created automatically. For example:

=www.example.com:12.34.56.79

+ (plus)

Exactly like the equals record, except that the reverse PTR record is not created. For example:

+mail.example.com:12.34.56.80

@ (at)

As suggested by the @ symbol, these records establish MX records. This example duplicates, in tinydns syntax, the same MX structure shown earlier in Example 5-1. For example:

@example.com:12.34.56.79:mail-a.example.com:10 @example.com:12.34.56.80:mail-b.example.com:20

C

CNAME records begin with the letter C as the first letter on the line. In this example, oldname.example.com is an alias for the true name server.example.com. The server.example.com name must have at least an A record associated with it. The name oldname.example.com cannot have any other records defined for it. For example:

Cserver.example.com:oldname.example.com

Putting several of these examples together, we create a data file that creates much of the same structure that is shown in Example 5-1, as shown in Example 5-9.

Example 5-9. tinydns configuration replicating Example 5-1

.example.com:12.34.56.81:ns.example.com =example.com:12.34.56.78 @example.com:12.34.56.79:mail-a.example.com:10 @example.com:12.34.56.80:mail-b.example.com:20 =www.example.com:12.34.56.78 @www.example.com:12.34.56.79:mail-a.example.com:10 @www.example.com:12.34.56.80:mail-b.example.com:20 =mail-a.example.com:12.34.56.79 @mail-a.example.com:12.34.56.79:mail-a.example.com:10 @mail-a.example.com:12.34.56.80:mail-b.example.com:20 =mail-b.example.com:12.34.56.80 @mail-b.example.com:12.34.56.79:mail-a.example.com:10 @mail-b.example.com:12.34.56.80:mail-b.example.com:20

It is a little unusual to see so many MX records in a DNS zone. If it is your intention that all email goes to exactly one mail server (or one set of organizational servers), then this is necessary. The rules for delivering email include vestigial accommodations for systems that have only an A record and no MX record. Mail transfer agents (MTAs) will try to deliver email directly to a host if it has only an A record and no MX record. So, if something (a misconfigured daemon, for example) sends mail to [e-mail] (instead of [e-mail]) these MX records will route the mail to the correct mail server .

5.6.2.2 Load balancing

The standard documentation suggests that you should always use the various add-* scripts when adding hosts and records to your zones. This will break down when you need to do anything beyond using mundane records (A, MX, NS, CNAME) in mundane ways. If, for example, you want to balance load across multiple web servers, DNS can assist with that. The standard method for doing this is to return multiple A records (IP addresses) for a given name. Example 5-10 shows the result of querying for www.google.com using dnsqr, the recursive querying tool that comes as part of djbdns.

Example 5-10. Multiple A records for load balancing

$ dnsqr a www.google.com 1 www.google.com: 433 bytes, 1+4+9+9 records, response, noerror query: 1 www.google.com answer: www.google.com 2663 CNAME www.google.akadns.net answer: www.google.akadns.net 269 A 216.239.39.99 answer: www.google.akadns.net 269 A 216.239.39.104 answer: www.google.akadns.net 269 A 216.239.39.147

In this case, the akadns.net nameserver returned three IP addresses. It turns out that each time you issue the same query, you will receive a set of three IP addresses, drawn randomly from the set of all valid IP addresses for www.google.com.

You can use tinydns to do this kind of load balancing, but it is not as simple as running the add-host script multiple times. The add-host script considers it an error if you try to define more than one IP address for a host, or if you try to define more than one host for an IP address. You must manually edit the data file to create multiple A records for a host name. There you can insert any valid combination of DNS records. Example 5-11 shows how to add three lines that assign three IP addresses to the name www.example.com.

Example 5-11. tinydns configuration file for load balancing

+www.example.com:12.34.56.78 +www.example.com:12.34.56.81 +www.example.com:12.34.56.82

If you have many IP addresses for a single machine, tinydns will return a randomly chosen set of eight IP addresses each time the name is queried. The number eight is not configurable, but is probably suitable for most applications.

5.6.2.3 Naming nameservers

Keep in mind that the add-* scripts with tinydns impose their own notion of machine naming on your zones. The add-ns script only takes a zone and an IP address as arguments. It will automatically name your nameservers without prompting you. If your zone is example.com, and your nameserver's IP address is 12.34.56.79, then the documentation recommends running add-ns example.com 12.34.56.79 to create your nameserver record in your zone. This will create a nameserver named a.ns.example.com. If you want a different naming scheme for your nameservers, you will have to edit the data file by hand. You sidestep the error checking features associated with djbdns when you create all the NS and SOA records by hand. Be sure you know what you are doing, if you take that course.