openSUSE Documentation
Chapter 22. The Domain Name System / 22.6. Zone Files
Prev22.5. The Configuration File /etc/named.conf22.7. Dynamic Update of Zone DataNext

22.6. Zone Files

Two types of zone files are needed. One assigns IP addresses to hostnames and the other does the reverse: it supplies a hostname for an IP address.

[Tip]Using the Dot in Zone Files

The . has an important meaning in the zone files. If hostnames are given without a final ., the zone is appended. Complete hostnames specified with a full domain name must end with a . to avoid having the domain added to it again. A missing or wrongly placed dot is probably the most frequent cause of name server configuration errors.

The first case to consider is the zone file example.com.zone, responsible for the domain example.com, shown in Example 22.6, “File /var/lib/named/example.com.zone”.

Example 22.6. File /var/lib/named/example.com.zone

1.  $TTL 2D 
2.  example.com. IN SOA      dns  root.example.com. ( 
3.               2003072441  ; serial
4.               1D          ; refresh
5.               2H          ; retry
6.               1W          ; expiry
7.               2D )        ; minimum
8.  
9.               IN NS       dns 
10.              IN MX       10 mail
11. 
12. gate         IN A        192.168.5.1 
13.              IN A        10.0.0.1 
14. dns          IN A        192.168.1.116 
15. mail         IN A        192.168.3.108 
16. jupiter      IN A        192.168.2.100
17. venus        IN A        192.168.2.101
18. saturn       IN A        192.168.2.102
19. mercury      IN A        192.168.2.103
20. ntp          IN CNAME    dns

Line 1:

$TTL defines the default time to live that should apply to all the entries in this file. In this example, entries are valid for a period of two days (2 D).

Line 2:

This is where the SOA (start of authority) control record begins:

  • The name of the domain to administer is example.com in the first position. This ends with ., because otherwise the zone would be appended a second time. Alternatively, @ can be entered here, in which case the zone would be extracted from the corresponding entry in /etc/named.conf.

  • After IN SOA is the name of the name server in charge as master for this zone. The name is expanded from dns to dns.example.com, because it does not end with a ..

  • An e-mail address of the person in charge of this name server follows. Because the @ sign already has a special meaning, . is entered here instead. For root@example.com the entry must read root.example.com.. The . must be included at the end to prevent the zone from being added.

  • The ( includes all lines up to ) into the SOA record.

Line 3:

The serial number is an arbitrary number that is increased each time this file is changed. It is needed to inform the secondary name servers (slave servers) of changes. For this, a 10 digit number of the date and run number, written as YYYYMMDDNN, has become the customary format.

Line 4:

The refresh rate specifies the time interval at which the secondary name servers verify the zone serial number. In this case, one day.

Line 5:

The retry rate specifies the time interval at which a secondary name server, in case of error, attempts to contact the primary server again. Here, two hours.

Line 6:

The expiration time specifies the time frame after which a secondary name server discards the cached data if it has not regained contact to the primary server. Here, it is a week.

Line 7:

The last entry in the SOA record specifies the negative caching TTL—the time for which results of unresolved DNS queries from other servers may be cached.

Line 9:

The IN NS specifies the name server responsible for this domain. dns is extended to dns.example.com because it does not end with a .. There can be several lines like this—one for the primary and one for each secondary name server. If notify is not set to no in /etc/named.conf, all the name servers listed here are informed of the changes made to the zone data.

Line 10:

The MX record specifies the mail server that accepts, processes, and forwards e-mails for the domain example.com. In this example, this is the host mail.example.com. The number in front of the hostname is the preference value. If there are multiple MX entries, the mail server with the smallest value is taken first and, if mail delivery to this server fails, an attempt is made with the next higher value.

Lines 12–19:

These are the actual address records where one or more IP addresses are assigned to hostnames. The names are listed here without a . because they do not include their domain, so example.com is added to all of them. Two IP addresses are assigned to the host gate, because it has two network cards. Wherever the host address is a traditional one (IPv4), the record is marked with AAAA. If the address is an IPv6 address, the entry is marked with AAAA 0. The previous token for IPv6 addresses was only AAAA, which is now obsolete.

[Note]IPv6 Syntax

The IPv6 record has a slightly different syntax than IPv4. Because of the fragmentation possibility, it is necessary to provide information about missed bits before the address. You must provide this information even if you want to use a completely unfragmented address. For the IPv4 record with the syntax

pluto IN            AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
pluto IN            AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

You need to add information about missing bits in IPv6 format. Because the example above is complete (does not miss any bits), the IPv6 format of this record is: 

pluto  IN            AAAA 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
pluto  IN            AAAA 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

Do not use IPv4 addresses with IPv6 mapping.

Line 20:

The alias ntp can be used to address dns (CNAME means canonical name).

The pseudodomain in-addr.arpa is used for the reverse lookup of IP addresses into hostnames. It is appended to the network part of the address in reverse notation. So 192.168 is resolved into 168.192.in-addr.arpa. See Example 22.7, “Reverse Lookup”.

Example 22.7. Reverse Lookup

1.  $TTL 2D
2.  168.192.in-addr.arpa.   IN SOA dns.example.com. root.example.com. (
3.                          2003072441      ; serial
4.                          1D              ; refresh
5.                          2H              ; retry
6.                          1W              ; expiry
7.                          2D )            ; minimum
8.
9.                          IN NS           dns.example.com.
10. 
11. 1.5                     IN PTR          gate.example.com. 
12. 100.3                   IN PTR          www.example.com. 
13. 253.2                   IN PTR          cups.example.com.

Line 1:

$TTL defines the standard TTL that applies to all entries here.

Line 2:

The configuration file should activate reverse lookup for the network 192.168. Given that the zone is called 168.192.in-addr.arpa, should not be added to the hostnames. Therefore, all hostnames are entered in their complete form—with their domain and with a . at the end. The remaining entries correspond to those described for the previous example.com example.

Lines 3–7:

See the previous example for example.com.

Line 9:

Again this line specifies the name server responsible for this zone. This time, however, the name is entered in its complete form with the domain and a . at the end.

Lines 11–13:

These are the pointer records hinting at the IP addresses on the respective hosts. Only the last part of the IP address is entered at the beginning of the line, without the . at the end. Appending the zone to this (without the .in-addr.arpa) results in the complete IP address in reverse order.

Normally, zone transfers between different versions of BIND should be possible without any problem.

Prev22.5. The Configuration File /etc/named.confHome22.7. Dynamic Update of Zone DataNext