19.3.2. Zone File Resource Records
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:
- This refers to the 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
Arecord 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
Arecord examples for the
server1 IN A 10.0.1.3 IN A 10.0.1.5Requests for
example.comare pointed to 10.0.1.3 or 10.0.1.5.
- This refers to the Canonical Name record, which maps one name to another. This type of record can also be referred to as an alias record.The next example tells
namedthat any requests sent to the <alias-name> should point to the host, <real-name>.
CNAMErecords are most commonly used to point to services that use a common naming scheme, such as
wwwfor Web servers.
<alias-name> IN CNAME <real-name>In the following example, an
Arecord binds a hostname to an IP address, while a
CNAMErecord points the commonly used
wwwhostname to it.
server1 IN A 10.0.1.5 www IN CNAME server1
- This refers to the 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>Here, the <preference-value> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The
MXresource 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.comemail server is preferred to the
mail2.example.comemail server when receiving email destined for the
- This refers to the NameServer record, which announces the authoritative nameservers for a particular zone.The following illustrates the layout of an
IN NS <nameserver-name>Here, <nameserver-name> should be an 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.
- This refers to the PoinTeR record, which is designed to point to another part of the namespace.
PTRrecords are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to Section 19.3.4, “Reverse Name Resolution Zone Files” for more examples of
PTRrecords in use.
- This refers to the Start Of Authority resource record, which proclaims important authoritative information about a namespace to the nameserver.Located after the directives, an
SOAresource record is the first resource record in a zone file.The following shows the basic structure of an
@ IN SOA <primary-name-server> <hostmaster-email> ( <serial-number> <time-to-refresh> <time-to-retry> <time-to-expire> <minimum-TTL> )The
@symbol places the
$ORIGINdirective (or the zone's name, if the
$ORIGINdirective is not set) as the namespace being defined by this
SOAresource 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
namedto 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 that 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.In BIND 4 and 8, the <minimum-TTL> directive is the amount of time other nameservers cache the zone's information. However, in BIND 9, the <minimum-TTL> directive defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (
3H).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 19.1, “Seconds compared to other time units” shows an amount of time in seconds and the equivalent time in another format.
Table 19.1. Seconds compared to other time units
Seconds Other Time Units
365DThe following example illustrates the form an
SOAresource 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