Creating a Zone Data File

2.2.1 Problem

You need to create a data file for a zone.

2.2.2 Solution

Using your favorite editor, create a file in the primary master name server's working directory. Name the file after the zone whose resource records it will contain. For example, for the foo.example zone, you might call the zone data file db.foo.example.

Begin the file with a $TTL control statement.[1] This tells other name servers (not those authoritative for the zone) how long they may cache records from this zone by specifying the zone's default time to live. You can specify the value as an integer number of seconds or as a scaled value: an integer followed by s for seconds, m for minutes, h for hours, d for days or w for weeks. For example, you can specify a time to live of one day with either:

[1] Assuming you're running a version of BIND newer than 8.2 -- and you should be.

$TTL 86400

or:

$TTL 1d

You can even concatenate two scaled values, like so:

$TTL 1d12h

Time to live values between one hour and one day are common.

Next, add an SOA record for the zone. The SOA record contains information about the whole zone, including how often the zone's slave name servers should check to see whether the zone has changed. The SOA record begins with the zone's domain name, a specification of the zone's class (which is almost always IN, for Internet), and the type mnemonic SOA. After the type, the SOA record requires seven fields:

The MNAME field

Specify the domain name of the zone's primary master name server.

The RNAME field

Specify an email address at which the administrator of the zone can be reached. Substitute a dot (".") for the "@" in the email address.

The zone's serial number

If you'll only be changing the zone manually, by editing the zone data file, consider using the format YYYYMMDDVV, where YYYY is the year, MM is the numeric month (from 1 to 12), DD is the date, and VV is a two-digit version number that starts at 00. This will give you a handy indicator of when you last updated the zone.

The zone's refresh value

This specifies how frequently slave name servers for the zone should check their master name server to see whether the zone's serial number has been incremented (indicating that the zone has changed). This value isn't particularly important if you use the NOTIFY mechanism, which enables your primary master name server to tell slaves when the zone changes, but values between one hour and three hours are common.

The zone's retry value

This specifies how often the zone's slave name servers should check their master name server after a check of the serial number has failed. As with refresh, this isn't that important if you use NOTIFY, but values between 15 minutes and 1 hour are common.

The zone's expire value

This specifies how long the zone's slave name servers will continue responding if they're unable to reach their master name server to find out the current serial number. Since this determines how long your slaves will answer queries for data in the zone in the event of an outage, you should make it fairly long. Values of several weeks to a month are common.

The zone's negative caching time to live value

This determines how long other name servers can cache negative answers given out by the zone's authoritative name servers. One such negative answer is NXDOMAIN, which indicates that the domain name the remote name server looked up doesn't exist in the zone. This value should be fairly low, between 15 minutes and 3 hours.

Here's a sample SOA record for the foo.example zone:

foo.example. IN SOA ns1.foo.example. (
 hostmaster.foo.example.
 2002040700
 1h
 15m
 30d
 1h )

Since we ran out of room for the record on the first line, we ended the line with "(", which tells the name server to treat all text between the "(" and a successive ")" as though it were on a single line. (We could also have just kept typing the whole record on a single line, but that would have been hard to read.)

Finally, add NS records listing the domain names of the authoritative name servers for the zone. You probably specified these name servers when you registered your domain name.

foo.example. IN NS ns1.foo.example.
foo.example. IN NS ns2.foo.example.
foo.example. IN NS ns.isp.net.

2.2.3 Discussion

The domain names in the resource records all end in dots to keep the name server from appending the origin to them. The default origin for a zone data file is just the domain name of the zone, which in this case is foo.example, so we could have written the SOA record as:

@ IN SOA ns1 (
 hostmaster
 2002040700
 1h
 15m
 30d
 1h )

("@" is short for "the current origin.")

Since these first several resource records in the zone are all attached to the same domain name (foo.example, in our example), you can specify the domain name for just the first of them and begin the rest of the records with whitespace (spaces or tabs):

@ IN SOA ns1 (
 hostmaster
 2002040700
 1h
 15m
 30d
 1h )

 IN NS ns1.foo.example.
 IN NS ns2.foo.example.
 IN NS ns.isp.net.

The name server interprets records that begin with whitespace as belonging to the most recently specified domain name.

2.2.4 See Also

Section 1.15 for creating a named.conf file, Section 1.16 for configuring a primary master name server, and Chapter 4 of DNS and BIND.