Zone files contain information about a
namespace and are stored in the named working
directory, /var/named/, by default. Each zone file
is named according to the file option data in the
zone statement, usually in a way that relates to the
domain in question and identifies the file as containing zone data, such
as example.com.zone.
Each zone file may contain directives and
resource records. Directives tell the
nameserver to perform tasks or apply special settings to the
zone. Resource records define the parameters of the zone and assign
identities to individual hosts. Directives are optional, but resource
records are required to provide name service to a zone.
All directives and resource records should be entered on individual
lines.
Comments can be placed after semicolon characters
(;) in zone files.
Directives begin with the dollar sign character
($) followed by the name of the directive. They
usually appear at the top of the zone file.
The following are commonly used directives:
$INCLUDE — Configures
named to include another zone file in this
zone file at the place where the directive appears. This allows
additional zone settings to be stored apart from the main zone
file.
$ORIGIN — Appends the domain name
to unqualified records, such as those with
the hostname and nothing more.
For example, a zone file may contain the following line:
$ORIGIN example.com.
Any names used in resource records that do not end in a
trailing period (.) are appended with
example.com.
Note
The use of the $ORIGIN directive is
unnecessary if the zone is specified in
/etc/named.conf because the zone name is
used as the value for the $ORIGIN directive
by default.
$TTL — Sets the default
Time to Live (TTL) value for the
zone. This is the length of time, in seconds, a zone resource
record is valid. Each resource record can contain its own TTL
value, which overrides this directive.
Increasing this value allows remote nameservers to cache the
zone information for a longer period of time, reducing the
number of queries for the zone and lengthening the amount of
time required to proliferate resource record changes.
The primary component of a zone file is its resource records.
There are many types of zone file resource records. The following are
used most frequently:
A — Address record,
which specifies an IP address to assign to a name, as in this
example:
<host> IN A <IP-address>
If the <host> value is
omitted, then an A record points to a default
IP address for the top of the namespace. This system is the
target for all non-FQDN requests.
Consider the following A
record examples for the
example.com zone file:
IN A 10.0.1.3
server1 IN A 10.0.1.5
Requests for example.com are
pointed to 10.0.1.3, while requests for
server1.example.com are pointed
to 10.0.1.5.
CNAME — Canonical name record, maps
one name to another. This type of record is also known as an
alias record.
The next example tells named that any
requests sent to the
<alias-name> should point to the
host, <real-name>.
CNAME records are most commonly used to point
to services that use a common naming scheme, such as
www for Web servers.
<alias-name> IN CNAME <real-name>
In the following example, an A record
binds a hostname to an IP address, while a
CNAME record points the commonly used
www hostname to it.
server1 IN A 10.0.1.5
www IN CNAME server1
MX — Mail eXchange
record, which tells where mail sent to a particular namespace
controlled by this zone should go.
IN MX <preference-value><email-server-name>
In this example, the
<preference-value> allows
numerical ranking of the email servers for a namespace, giving
preference to some email systems over others. The
MX resource record with the lowest
<preference-value> is preferred
over the others. However, multiple email servers can possess the
same value to distribute email traffic evenly among them.
The <email-server-name> may
be a hostname or FQDN.
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
In this example, the first
mail.example.com email server is
preferred to the
mail2.example.com email server
when receiving email destined for the
example.com domain.
NS — NameServer record, which announces
the authoritative nameservers for a particular zone.
This is an example of an NS record:
IN NS <nameserver-name>
The <nameserver-name>
should be a FQDN.
Next, two nameservers are listed as authoritative for the
domain. It is not important whether these nameservers are slaves
or if one is a master; they are both still considered
authoritative.
IN NS dns1.example.com.
IN NS dns2.example.com.
PTR — PoinTeR record, designed to point
to another part of the namespace.
PTR records are primarily
used for reverse name resolution, as they point IP addresses
back to a particular name. Refer to Section 12.3.4 Reverse Name Resolution Zone Files for more examples
of PTR records in use.
SOA — Start Of
Authority resource record, proclaims important authoritative
information about a namespace to the nameserver.
Located after the directives, an
SOA resource record is the first
resource record in a zone file.
The following example shows the basic structure of an
SOA resource record:
@ IN SOA <primary-name-server><hostmaster-email> (
<serial-number><time-to-refresh><time-to-retry><time-to-expire><minimum-TTL> )
The @ symbol places the
$ORIGIN directive (or the zone's name, if the
$ORIGIN directive is not set) as the
namespace being defined by this SOA resource
record. The hostname of the primary nameserver that is
authoritative for this domain is the
<primary-name-server> directive, and the
email of the person to contact about this namespace is the
<hostmaster-email> directive.
The <serial-number> directive
is a numerical value incremented every time the zone file is
altered to indicate it is time for named to
reload the zone. The
<time-to-refresh> directive is
the numerical value slave servers use to determine how long to
wait before asking the master nameserver if any changes have been
made to the zone. The
<serial-number> directive is a
numerical value used by the slave servers to determine if it is
using outdated zone data and should therefore refresh it.
The <time-to-retry> directive
is a numerical value used by slave servers to determine the length
of time to wait before issuing a refresh request in the event the
master nameserver is not answering. If the master has not replied
to a refresh request before the amount of time specified in the
<time-to-expire> directive
elapses, the slave servers stop responding as an authority for
requests concerning that namespace.
The <minimum-TTL> directive is the
quantity of time other nameservers cache the zone's information.
When configuring BIND, all times are specified in
seconds. However, it is possible to use abbreviations when
specifying units of time other than seconds, such as minutes
(M), hours (H), days
(D), and weeks (W). The
table in Table 12-1 shows an amount of
time in seconds and the equivalent time in another format.
Seconds
Other Time Units
60
1M
1800
30M
3600
1H
10800
3H
21600
6H
43200
12H
86400
1D
259200
3D
604800
1W
31536000
365D
Table 12-1. Seconds compared to other time units
The following example illustrates the form an SOA
resource record might take when it is populated with real values.
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
Seen individually, directives and resource records can be difficult to
grasp. However, when placed together in a single file, they become
easier to understand.
The following example shows a very basic zone file.
$ORIGIN example.com.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS dns1.example.com.
IN NS dns2.example.com.
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
IN A 10.0.1.5
server1 IN A 10.0.1.5
server2 IN A 10.0.1.7
dns1 IN A 10.0.1.2
dns2 IN A 10.0.1.3
ftp IN CNAME server1
mail IN CNAME server1
mail2 IN CNAME server2
www IN CNAME server2
In this example, standard directives and SOA
values are used. The authoritative nameservers are set as
dns1.example.com and
dns2.example.com, which have A
records that tie them to 10.0.1.2 and
10.0.1.3, respectively.
The email servers configured with the MX records
point to server1 and
server2 via CNAME
records. Since the server1 and
server2 names do not end in a
trailing period (.), the
$ORIGIN domain is placed after them, expanding them
to server1.example.com and
server2.example.com. Through the related
A resource records, their IP addresses can be
determined.
FTP and Web services, available at the standard
ftp.example.com and
www.example.com names, are pointed at the
appropriate servers using CNAME records.
A reverse name resolution zone file is used to translate an IP
address in a particular namespace into a FQDN. It looks very similar
to a standard zone file, except that PTR resource
records are used to link the IP addresses to a fully qualified
domain name.
A PTR record looks similar to this:
<last-IP-digit> IN PTR <FQDN-of-system>
The <last-IP-digit> is the last
number in an IP address which points to a particular system's FQDN.
In the follow example, IP addresses
10.0.1.20 through
10.0.1.25 are pointed to
corresponding FQDNs.
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS dns1.example.com.
IN NS dns2.example.com.
20 IN PTR alice.example.com.
21 IN PTR betty.example.com.
22 IN PTR charlie.example.com.
23 IN PTR doug.example.com.
24 IN PTR ernest.example.com.
25 IN PTR fanny.example.com.
This zone file would be called into service with a
zone statement in the
named.conf file which looks similar to the
following:
zone "1.0.10.in-addr.arpa" IN {
type master;
file "example.com.rr.zone";
allow-update { none; };
};
There is very little difference between this example and a standard
zone statement, except for the zone name. Note
that a reverse name resolution zone requires the first three blocks
of the IP address reversed followed by
.in-addr.arpa. This allows the single block of IP
numbers used in the reverse name resolution zone file to be
associated with the zone.
