2.13 Using a Single Data File for Multiple Zones

2.13.1 Problem

You want to use a single data file for multiple zones.

2.13.2 Solution

Create a "template" zone data file. Make sure that all of the owner names of records in the zone are "@" (short for the origin) or relative; that is, written without a trailing dot. For example:

@    IN    SOA    ns1.isp.net. hostmaster.isp.net. (
     2002040900
     3600
     900
     604800
     3600 )

    IN    NS    ns1.isp.net.
    IN    NS    ns2.isp.net.

    IN    MX    smtp.isp.net.

    IN    A    192.168.0.99

www IN    CNAME    @

Add zone statements to your name server's named.conf file, configuring it as primary master for the various zones, and specifying the "template" zone data file in the file substatement each time. For example:

zone "foo.example" {
    type master;
    file "db.template";
};

zone "bar.example" {
    type master;
    file "db.template";
};

zone "baz.example" {
    type master;
    file "db.template";
};

Since each zone statement sets the default origin to the domain name of the zone in the data file, the SOA record and NS records will always end up attached to the right domain name, and the rest of the records will end up "translated" into the zone.

2.13.3 Discussion

This technique will only work if all of the zones are very similar -- nearly identical, in fact. The zones must contain the same number and mix of records, and the records in the zones can only differ by the domain name of the zone. For example, if the domain name www.foo.example is an alias for a.foo.example in the foo.example zone, then www.bar.example will be an alias for a.bar.example in the bar.example zone.

The name server must be the primary master for all of the zones; there's no way to set up an equivalent slave name server that uses the same backup zone data file for all of its zones, since name servers write fully qualified domain names to backup zone data files.

Also, none of the zones can be dynamically updated, since dynamic updates to a zone would cause the name server to rewrite the zone data file, and the rewritten zone data file would also contain fully qualified domain names.

2.13.4 See Also

Section 2.2 for understanding the default origin of a zone data file.

2.14 Using Multiple Data Files for a Single Zone

2.14.1 Problem

You want to break a zone into multiple data files, possibly to organize the large number of resource records logically.

2.14.2 Solution

Use the $INCLUDE control statement in your top-level zone data file, which interpolates the contents of another file. For example, to include the contents of the file db.foo.example. hosts into the data file for the zone foo.example , you could use this $INCLUDE control statement:

$INCLUDE db.foo.example.hosts

2.14.3 Discussion

The origin in the included file is, by default, the same as the origin in the file that includes it. If you'd like to change the origin in the included file, specify the new origin as the second argument to the $INCLUDE control statement:

$INCLUDE db.subdomain.foo.example.hosts subdomain.foo.example

On the line after the $INCLUDE statement, the origin reverts to its previous setting.

2.14.4 See Also

Section 2.9, which explains how to create a subdomain within the same zone.

2.15 Resetting Your Zone's Serial Number

2.15.1 Problem

You need to reset your serial number to some low value, possibly because you inadvertently added a digit to it.

2.15.2 Solution

If you've accidentally incremented your serial number to a value larger than 2 ³² - 1 (4,294,967,295), first find out what your current serial number is -- because it probably isn't what you think it is (the serial number is only 32 bits large). The easiest way to do this is to use a query tool, such as dig , to look up your zone's SOA record:

$ dig soa foo.example

; <<>> DiG 9.2.1 <<>> soa foo.example
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4335
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;foo.example.                   IN      SOA

;; ANSWER SECTION:
foo.example.            86400   IN      SOA     ns1.foo.example. hostmaster.foo.
example. 2002021239 3600 900 2592000 3600

If the current serial number is less than 2,147,483,647, add 2,147,483,647 to the serial number. Wait for all of your zone's slave name servers to pick up the new version of the zone (if you're using NOTIFY, that shouldn't take long). Then set the serial number to your target.

If the current serial number is larger than 2,147,483,647, just set the serial number to the number you want.

2.15.3 Discussion

Whahuh? Why on Earth does this work?

Name servers compare serial numbers using sequence space arithmetic , which ain't your grandpa's 'rithmetic. In sequence space arithmetic, you have a finite set of integers, but each number has a " next " number. After 0 comes 1, then 2, all the way to 4,294,967,295 (2 ³² - 1). The next number after 4,294,967,295 is 0. Think of it like a clock: The hour after 1:00 is 2:00, and the hour after 12:00 is 1:00.

Half of the numbers are larger than any given number, and the other half are smaller. With a set of 2 ³² possible serial numbers, half (2 ³¹ - 1, actually) are larger than any given serial number, and half are smaller.

Consider the serial number 1,000,000,000. The next 2 ³¹ - 1 serial numbers, 1,000,000,001 through 3,147,483,647, are larger. The 2 ³¹ - 1 serial numbers after that, 3,147,483,648 through 4,294,967,295 (2 ³² - 1) and 0 to 999,999,999, are smaller. Yes, Alice, in the world of serial numbers, 3,147,483,648 is smaller than 1,000,000,000.

So when you add 2,147,483,647 (2 ³¹ - 1) to a serial number, you're actually adding the largest increment possible -- add a larger number and the result will actually be smaller than the old serial number, and your zone's slaves won't transfer the zone.

Once all the slaves have the new zone, you can simply set the serial number to the serial number you want, which is now considered larger than the current serial number.

If you're not comfortable with this New Math, try out the script reset_serial.pl , included in the tar file that accompanies this book (see the Preface for where to get it). reset_serial.pl takes as arguments your current serial number and the serial number you want to get to, and tells you how to get there.

There's also a brute force method for resetting your serial number: set the serial number to your target in the zone data file. Then delete your zone's backup data files on all of your slaves and restart named . Your slave name servers won't have any choice but to transfer the zone, regardless of its serial number.

This won't work if you don't have administrative control of all of your slaves, of course, and it has all the elegance of using a flat-head screwdriver as a chisel.