Organizing Your Files (DNS and BIND, 4th Edition)

7.3. Organizing Your Files

Back when you first set up your zones, organizing your files was simple -- you put them all in a single directory. There was one configuration file and a handful of zone data files. Over time, though, your responsibilities grew. More networks were added and hence more in-addr.arpazones. Maybe you delegated a few subdomains. You started backing up zones for other sites. After a while, an ls of your name server directory no longer fit on a single screen. It's time to reorganize. BIND has a few features that will help with this reorganization.

BIND 4.9 and later name servers support a configuration file statement, called include, which allows you to insert the contents of a file into the current configuration file. This lets you take a very large configuration file and break it into smaller pieces.

Zone data files (for all BIND versions) support two [52] control statements: $ORIGIN and $INCLUDE. The$ORIGINstatement changes a zone data file's origin, and $INCLUDE inserts a new file into the current zone data file. These control statements are not resource records; they facilitate the maintenance of DNS data. In particular, they make it easier for you to divide your zone into subdomains by allowing you to store the data for each subdomain in a separate file.

[52]Three if you count $TTL, which BIND 8.2 and later name servers support.

7.3.1. Using Several Directories

One way to organize your zone data files is to store them in separate directories. If your name server is a primary master for several sites' zones (both forward- and reverse-mapping), you could store each site's zone data files in its own directory. Another arrangement might be to store all the primary master zones' data files in one directory and all the backup zone data files in another. Let's look at what the BIND 4 configuration file might look like if you chose to split up your primary master and slave zones:

directory /var/named
;
; These files are not specific to any zone
;
cache    .                         db.cache
primary  0.0.127.in-addr.arpa      db.127.0.0
;
; These are our primary zone files
;
primary  movie.edu                 primary/db.movie.edu
primary  249.249.192.in-addr.arpa  primary/db.192.249.249
primary  253.253.192.in-addr.arpa  primary/db.192.253.253
;
; These are our slave zone files
;
secondary ora.com                  198.112.208.25 slave/bak.ora.com
secondary 208.112.198.in-addr.arpa 198.112.208.25 slave/bak.198.112.208

Here's the same configuration file in BIND 8 format:

options { directory "/var/named"; };
//
// These files are not specific to any zone
//
zone "." {
        type hint;
        file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "db.127.0.0";
};
//
// These are our primary zone files
//
zone "movie.edu" {
        type master;
        file "primary/db.movie.edu";
};
zone "249.249.192.in-addr.arpa" {
        type master;
        file "primary/db.192.249.249";
};
zone "253.253.192.in-addr.arpa" {
        type master;
        file "primary/db.192.253.253";
};
//
// These are our slave zone files
//
zone "ora.com" {
        type slave;
        file "slave/bak.ora.com";
        masters { 198.112.208.25; };
};
zone "208.112.192.in-addr.arpa" {
        type slave;
        file "slave/bak.198.112.208";
        masters { 198.112.208.25; };
};

Another variation on this division is to break the configuration file into three files: the main file, a file that contains all the primary entries, and a file that contains all the secondary entries. Here's what the main BIND 4 configuration file might look like:

directory /var/named
;
; These files are not specific to any zone
;
cache    .                         db.cache
primary  0.0.127.in-addr.arpa      db.127.0.0
;
include  named.boot.primary
include  named.boot.slave

Here is named.boot.primary (BIND 4):

;
; These are our primary zone files
;
primary  movie.edu                 primary/db.movie.edu
primary  249.249.192.in-addr.arpa  primary/db.192.249.249
primary  253.253.192.in-addr.arpa  primary/db.192.253.253

Here is named.boot.slave (BIND 4):

;
; These are our slave zone files
;
secondary ora.com                  198.112.208.25 slave/bak.ora.com
secondary 208.112.198.in-addr.arpa 198.112.208.25 slave/bak.198.112.208

Here are the same files in BIND 8 or 9 format:

options { directory "/var/named"; };
//
// These files are not specific to any zone
//
zone "." {
        type hint;
        file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "db.127.0.0";
};

include "named.conf.primary";
include "named.conf.slave";

Here is named.conf.primary (BIND 8 or 9):

//
// These are our primary zone files
//
zone "movie.edu" {
        type master;
        file "primary/db.movie.edu";
};
zone "249.249.192.in-addr.arpa" {
        type master;
        file "primary/db.192.249.249";
};
zone "253.253.192.in-addr.arpa" {
        type master;
        file "primary/db.192.253.253";
};

Here is named.conf.slave (BIND 8 or 9):

//
// These are our slave zone files
//
zone "ora.com" {
        type slave;
        file "slave/bak.ora.com";
        masters { 198.112.208.25; };
};
zone "208.112.192.in-addr.arpa" {
        type slave;
        file "slave/bak.198.112.208";
        masters { 198.112.208.25; };
};

You might think the organization would be better if you put the configuration file with the primary directives into the primary subdirectory by adding a new directory directive to change to this directory, and remove the primary/ from each of the filenames since the name server is now running in that directory. Then you could make comparable changes in the configuration file with the secondary lines. Unfortunately, that doesn't work. BIND 8 and 9 name servers allow you to define only a single working directory. BIND 4 name servers let you redefine the working directory with multiple directory directives, but that's more of an oversight than a feature. Things get rather confused when the name server keeps switching around to different directories -- backup zone data files end up in the last directory the name server changed to, and when the name server is reloaded, it may not be able to find the main configuration file if it isn't left in the directory where it started (if the configuration file is specified with a relative pathname).

7.3.2. Changing the Origin in a Zone Data File

With BIND, the default origin for the zone data files is the second field of the primary or secondary directive in a BIND 4 named.boot file, or the second field of the zone statement in a BIND 8 or 9 named.conf file. The origin is a domain name that is automatically appended to all names in the file that don't end in a dot. This origin can be changed in the zone data file with the $ORIGIN control statement. In the zone data file, $ORIGIN is followed by a domain name. (Don't forget the trailing dot if you use the full domain name!) From this point on, all names that don't end in a dot have the new origin appended. If your zone (e.g., movie.edu) has a number of subdomains, you can use the $ORIGIN statement to reset the origin and simplify the zone data file. For example:

$ORIGIN classics.movie.edu.
maltese       IN  A  192.253.253.100
casablanca    IN  A  192.253.253.101

$ORIGIN comedy.movie.edu.
mash          IN  A  192.253.253.200
twins         IN  A  192.253.253.201

We'll cover creating subdomains in more depth in Chapter 9, "Parenting".

7.3.3. Including Other Zone Data Files

Once you've subdivided your zone like this, you might find it more convenient to keep each subdomain's records in separate files. The $INCLUDE control statement lets you do this:

$ORIGIN classics.movie.edu.
$INCLUDE db.classics.movie.edu

$ORIGIN comedy.movie.edu.
$INCLUDE db.comedy.movie.edu

To simplify the file even further, you can specify the included file and the new origin on a single line:

$INCLUDE db.classics.movie.edu classics.movie.edu.
$INCLUDE db.comedy.movie.edu   comedy.movie.edu.

When you specify the origin and the included file on a single line, the origin change applies only to the particular file that you're including. For example, the comedy.movie.edu origin applies only to the names in db.comedy.movie.edu. After db.comedy.movie.edu has been included, the origin returns to what it was before $INCLUDE, even if there was an $ORIGIN statement within db.comedy.movie.edu.