[Chapter 7] 7.3 Organizing Your Files

7.3 Organizing Your Files

When you first set up your domain, organizing your files was simple - you put them all in a single directory. There was one configuration file and a handful of db files. Over time, your responsibilities grew. More networks were added. Maybe a few subdomains were started. You started backing up zones for other sites. After a while, an ls of your name server directory no longer fits on a single screen. It's time to reorganize. BIND has a few features that will help with your organization.

The configuration file for a 4.9 or later server can have a control entry, called include , which allows you to insert a new configuration file into the current configuration file. This allows you to take a very large configuration file and break it into smaller pieces. The database files (for all BIND versions) allow two control entries: $ORIGIN and $INCLUDE . $ORIGIN changes the origin, and $INCLUDE inserts a new file into the current file. The database control entries are not resource records; they facilitate the maintenance of DNS data. In particular, these statements make it easier for you to divide your domain into subdomains: they allow you to store the data for each subdomain in a separate database file.

7.3.1 Using Several Directories

One way to organize your db files is to store them in separate directories. If your server is a primary master for several sites (both forward and reverse maps), you could store each site's db files in its own directory. Another division might be to store all the primary master files in one directory and all the slave backup files in a different directory. Let's look at what the version 4 configuration file might look like if you chose the primary/slave division:

directory /usr/local/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
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
secondary 208.112.198.in-addr.arpa 198.112.208.25 slave/bak.198.112.208

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

options { directory "/usr/local/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";
};
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";
        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 version 4 main configuration file might look like:

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

Here is conffile.primary (version 4):

;
; These are our primary zone files
;
primary  movie.edu                 primary/db.movie
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 conffile.slave (version 4):

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

Here are the same files in version 8 format:

options { directory "/usr/local/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 "conffile.primary";
include "conffile.slave";

Here is conffile.primary (version 8):

//
// These are our primary zone files
//
zone "movie.edu" {
        type master;
        file "primary/db.movie";
};
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 conffile.slave (version 8):

//
// These are our slave zone files
//
zone "ora.com" {
        type slave;
        file "slave/bak.ora";
        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 entries into the primary subdirectory, add a new directory line to change to this directory, and remove the primary/ from each of the file names, since the server is now in that directory. Then make comparable changes in the configuration file with the secondary lines. But things get rather confused when the name server keeps switching around to different directories - the slave backup files end up in the last directory the name server changed to, and when the name server is sent a HUP signal, it may not be able to find the main configuration file if it is not left in the directory where it started (if the configuration file is specified with a relative path name).

7.3.2 Changing the Origin in a Database File

With BIND , the default origin for the DNS database files is the second field of the primary or secondary statement in the version 4 named.boot file or the second field of the zone statement in the version 8 named.conf file. The origin is a domain name that is appended automatically to all names not ending in a dot. This origin can be changed in the db file with $ORIGIN . In the db file, $ORIGIN is followed by a domain name. (Don't forget the trailing dot if you give the full domain name!) From this point on, all names not ending in a dot have the new origin appended. If your name server (e.g., movie.edu ) is responsible for a number of subdomains, you can use the $ORIGIN entry to reset the origin and simplify the files. 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 more on creating subdomains in Chapter 9, Parenting .

7.3.3 Including Other Database Files

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

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

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

To simplify the file even further, the new origin can be specified on the $INCLUDE line:

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

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