12.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:

A — Address record, which specifies an IP address to assign to a name, as in this example:
```
<host>     IN     A     <IP-address>
```
```
<host>     IN     A     <IP-address>
```
Copy to Clipboard Toggle word wrap
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
```
```
             IN     A       10.0.1.3
server1      IN     A       10.0.1.5
```
Copy to Clipboard Toggle word wrap
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>
```
```
<alias-name>     IN     CNAME       <real-name>
```
Copy to Clipboard Toggle word wrap
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
```
```
server1      IN     A       10.0.1.5
www          IN     CNAME   server1
```
Copy to Clipboard Toggle word wrap
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     MX     <preference-value>  <email-server-name>
```
Copy to Clipboard Toggle word wrap
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     MX     10     mail.example.com.
      IN     MX     20     mail2.example.com.
```
Copy to Clipboard Toggle word wrap
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>
```
```
      IN     NS     <nameserver-name>
```
Copy to Clipboard Toggle word wrap
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.
```
```
      IN     NS     dns1.example.com.
      IN     NS     dns2.example.com.
```
Copy to Clipboard Toggle word wrap
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> )
```
```
@     IN     SOA    <primary-name-server>     <hostmaster-email> (
                    <serial-number>
                    <time-to-refresh>
                    <time-to-retry>
                    <time-to-expire>
                    <minimum-TTL> )
```
Copy to Clipboard Toggle word wrap
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, “Seconds compared to other time units” shows an amount of time in seconds and the equivalent time in another format.
Expand
Table 12.1. Seconds compared to other time units
Seconds Other Time Units
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D
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
```
```
@     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
```
Copy to Clipboard Toggle word wrap

Table 12.1. Seconds compared to other time units
Seconds	Other Time Units
`60`	`1M`
`1800`	`30M`
`3600`	`1H`
`10800`	`3H`
`21600`	`6H`
`43200`	`12H`
`86400`	`1D`
`259200`	`3D`
`604800`	`1W`
`31536000`	`365D`

Voltar ao topo

Este conteúdo não está disponível no idioma selecionado.

12.3.2. Zone File Resource Records

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Tornando o open source mais inclusivo

Sobre a Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links