|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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:
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:
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:
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.
|
|
|
