17.2.2. Editing Zone Files As outlined in Section 17.1.1, "Nameserver Zones" , zone files contain information about a namespace. They are stored in the named working directory located in /var/named/ by default, and each zone file is named according to the file option 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 . Table 17.5. The named service zone files Path Description /var/named/ The working directory for the named service. The nameserver is not allowed to write to this directory. /var/named/slaves/ The directory for secondary zones. This directory is writable by the named service. /var/named/dynamic/ The directory for other files, such as dynamic DNS (DDNS) zones or managed DNSSEC keys. This directory is writable by the named service. /var/named/data/ The directory for various statistics and debugging files. This directory is writable by the named service. A zone file consists of 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. While the directives are optional, the resource records are required in order to provide name service to a zone. All directives and resource records should be entered on individual lines. 17.2.2.1. Common Directives Directives begin with the dollar sign character followed by the name of the directive, and usually appear at the top of the file. The following directives are commonly used in zone files: USDINCLUDE The USDINCLUDE directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file. Example 17.7. Using the USDINCLUDE directive USDORIGIN The USDORIGIN directive allows you to append the domain name to unqualified records, such as those with the host name only. Note that the use of this directive is not necessary if the zone is specified in /etc/named.conf , since the zone name is used by default. In Example 17.8, "Using the USDORIGIN directive" , any names used in resource records that do not end in a trailing period are appended with example.com . Example 17.8. Using the USDORIGIN directive USDTTL The USDTTL directive allows you to set the default Time to Live (TTL) value for the zone, that is, how long is a zone record 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 propagate resource record changes. Example 17.9. Using the USDTTL directive 17.2.2.2. Common Resource Records The following resource records are commonly used in zone files: A The Address record specifies an IP address to be assigned to a name. It takes the following form: If the hostname value is omitted, the record will point to the last specified hostname . In Example 17.10, "Using the A resource record" , the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5 . Example 17.10. Using the A resource record CNAME The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record . It takes the following form: CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. However, there are multiple restrictions for their usage: CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops. CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed. Other resource record that point to the fully qualified domain name (FQDN) of a host (that is, NS, MX, PTR) should not point to a CNAME record. In Example 17.11, "Using the CNAME resource record" , the A record binds a host name to an IP address, while the CNAME record points the commonly used www host name to it. Example 17.11. Using the CNAME resource record MX The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go. It takes the following form: The email-server-name is a fully qualified domain name (FQDN). 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. In Example 17.12, "Using the MX resource record" , 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. Example 17.12. Using the MX resource record NS The Nameserver record announces authoritative nameservers for a particular zone. It takes the following form: The nameserver-name should be a fully qualified domain name (FQDN). Note that when two nameservers are listed as authoritative for the domain, it is not important whether these nameservers are secondary nameservers, or if one of them is a primary server. They are both still considered authoritative. Example 17.13. Using the NS resource record PTR The Pointer record points to another part of the namespace. It takes the following form: The last-IP-digit directive is the last number in an IP address, and the FQDN-of-system is a fully qualified domain name (FQDN). PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. See Section 17.2.2.4.2, "A Reverse Name Resolution Zone File" for more examples of PTR records in use. SOA The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file. It takes the following form: The directives are as follows: The @ symbol places the USDORIGIN directive (or the zone's name if the USDORIGIN directive is not set) as the namespace being defined by this SOA resource record. The primary-name-server directive is the host name of the primary nameserver that is authoritative for this domain. The hostmaster-email directive is the email of the person to contact about the namespace. The serial-number directive is a numerical value incremented every time the zone file is altered to indicate it is time for the named service to reload the zone. The time-to-refresh directive is the numerical value secondary nameservers use to determine how long to wait before asking the primary nameserver if any changes have been made to the zone. The time-to-retry directive is a numerical value used by secondary nameservers to determine the length of time to wait before issuing a refresh request in the event that the primary nameserver is not answering. If the primary server has not replied to a refresh request before the amount of time specified in the time-to-expire directive elapses, the secondary 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. In BIND 9, it defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (that is, 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 ). Table 17.6, "Seconds compared to other time units" shows an amount of time in seconds and the equivalent time in another format. Table 17.6. 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 Example 17.14. Using the SOA resource record 17.2.2.3. Comment Tags Additionally to resource records and directives, a zone file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to the user. Any text after the semicolon character to the end of the line is considered a comment. For example: 17.2.2.4. Example Usage The following examples show the basic usage of zone files. 17.2.2.4.1. A Simple Zone File Example 17.15, "A simple zone file" demonstrates the use of standard directives and SOA values. Example 17.15. A simple zone file In this example, the authoritative nameservers are set as dns1.example.com and dns2.example.com , and are tied to the 10.0.1.1 and 10.0.1.2 IP addresses respectively using the A record. The email servers configured with the MX records point to mail and mail2 via A records. Since these names do not end in a trailing period, the USDORIGIN domain is placed after them, expanding them to mail.example.com and mail2.example.com . Services available at the standard names, such as www.example.com ( WWW ), are pointed at the appropriate servers using the CNAME record. This zone file would be called into service with a zone statement in the /etc/named.conf similar to the following: 17.2.2.4.2. A Reverse Name Resolution Zone File A reverse name resolution zone file is used to translate an IP address in a particular namespace into an fully qualified domain name (FQDN). It looks very similar to a standard zone file, except that the PTR resource records are used to link the IP addresses to a fully qualified domain name as shown in Example 17.16, "A reverse name resolution zone file" . Example 17.16. A reverse name resolution zone file In this example, IP addresses 10.0.1.1 through 10.0.1.6 are pointed to the corresponding fully qualified domain name. This zone file would be called into service with a zone statement in the /etc/named.conf file similar to the following: 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.

Commands:
USDINCLUDE /var/named/penguin.example.com
USDORIGIN example.com.
USDTTL 1D
hostname IN A IP-address
server1 IN A 10.0.1.3 IN A 10.0.1.5
alias-name IN CNAME real-name
server1 IN A 10.0.1.5 www IN CNAME server1
IN MX preference-value email-server-name
example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com.
IN NS nameserver-name
IN NS dns1.example.com. IN NS dns2.example.com.
last-IP-digit IN PTR FQDN-of-system
@ IN SOA primary-name-server hostmaster-email ( serial-number time-to-refresh time-to-retry time-to-expire minimum-TTL )
@ 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
604800 ; expire after 1 week
USDORIGIN example.com. USDTTL 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. dns1 IN A 10.0.1.1 IN AAAA aaaa:bbbb::1 dns2 IN A 10.0.1.2 IN AAAA aaaa:bbbb::2 ; ; @ IN MX 10 mail.example.com. IN MX 20 mail2.example.com. mail IN A 10.0.1.5 IN AAAA aaaa:bbbb::5 mail2 IN A 10.0.1.6 IN AAAA aaaa:bbbb::6 ; ; ; This sample zone file illustrates sharing the same IP addresses ; for multiple services: ; services IN A 10.0.1.10 IN AAAA aaaa:bbbb::10 IN A 10.0.1.11 IN AAAA aaaa:bbbb::11 ftp IN CNAME services.example.com. www IN CNAME services.example.com. ; ;
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
USDORIGIN 1.0.10.in-addr.arpa. USDTTL 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. ; 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. ; 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. ; 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.
zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };