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 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.
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.
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.
|
