DNS: Zone Files (continued)

DNS Zone Files 1
Tech Articles
This article describes BIND (DNS)  administration and is intended for experienced UNIX administrators. Go to these tutorials on DNS Queries   or DNS settings for more introductory information. 
DNS Zone Files (continued)

File Name
Most sites follow the convention of calling the zone file db.DOMAIN or db.ADDR. The zone file name should match the file option is the zone statement described at the end of this page. In this example the file would be called:
db.192.168.22

Explanation
Reverse name resolution zone files (often referred to as “the reverse file”) use PTR resource records to translate an IP address into an FQDN (fully qualified domain name).

A sample reverse file is on the right.

An example for a PTR record is:
5  IN  PTR  mail1.petervtamas.com.

The address should point to the canonical name only and not to an alias.

$ORIGIN directive:  The first three blocks of the IP address reversed followed by .in-addr.arpa. Therefore, all the addresses referenced in this zone file start with the same three blocks, in this example 192.168.22.

Otherwise, the reverse file is very similar to the zone file described in the previous document . Here is another information again, feel free to skip ahead to the next page if all the components of the example on the right is clear.

Explanation of Items Similar to Other Zone Files

Comments start with ;

The first resource record in a zone file is the SOA (Start of Authority). The SOA directive announces important authoritative information about the name space to the name server.

The @ symbol indicates the namespace being defined by this SOA resource record, as defined by @ORIGIN.

The primary-name-server directive will be the hostname of the primary nameserver that is authoritative for this domain. In this example, it is dns1.petervtamas.com

The hostmaster-email directive is the email address of the contact for this namespace. This information is intended for humans and not the name server. Note that the first dot in this directive should be replaced with @ so that hostmaster.petervtamas.com becomes hostmaster@petervtamas.com (note also that this is a fictitious address).

The serial number directive must be incremented every time the zone file is updated. Many organizations follow a convention that the serial number is based on the date with the following format: YYYYMMDDNN which is year, month, date and a two digit number starting with 00 or 01. There is no technical reason to follow this convention, it just makes it easier to notice if the serial number has not been updated.

The examples for the next four directives use a numerical value in seconds. Other units of time can be used as well, such as 3D for 3 days or 1W for 1 week.  RFC 1537 makes best practices recommendations including specific values for these directives. 

The time-to-refresh directive indicates how long the secondary nameservers should wait before checking primary name server for changes made to the zone. RFC 1537 recommends 8 hours (28800 seconds).

The time-to-retry directive indicates how long the secondary nameservers should wait before sending another request to the primary name server for changes made to the zone. RFC 1537 recommends 2 hours (7200 seconds).

The time-to-expire directive indicates how long the secondary servers should wait after the last time a primary name server has responded to a refresh request. RFC 1537 recommends one week (604800 seconds), which gives the systems administrators plenty of time to repair or replace a primary name server that went down. Once this time elapses, the secondary server stops giving out information about this zone. The assumptions are that:
not responding is better than responding with outdated data
the primary may not be down, there may just be a networking issue between this primary and the secondary.

The minimum-TTL directive is the amount of time other name servers cache the zone’s information. RFC 1537 recommends one day (86400 seconds).


Suggestions for Future Learning

RedHat has a networking document with a nice section on DNS:

This is also a good article from RedHat:

RFC 1912 and its predeessor  RFC 1537 make best practices recommendations including specific values for many directives.

Sample reverse name resolution zone file

$ORIGIN 22.168.192.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.petervtamas.com.  hostmaster.petervtamas.com. (
       2016091300  ; 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.petervtamas.com.
;
1  IN  PTR  dns1.petervtamas.com.
2  IN  PTR  dns2.petervtamas.com.
;
5  IN  PTR  mail1.petervtamas.com.
6  IN  PTR  mail2.petervtamas.com.
;
 
 
Add this zone statement to /etc/named.conf
 
zone "22.168.192.in-addr.arpa" IN {
  type master;
  file "db.192.168.22";
  allow-update { none; };
};
 




DNS Zone Files 1
Tech Articles