DNS: Zone File

Tech Articles
Zone Files 2
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

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:

Explanation of example, on right

Comments start with ;

$ORIGIN directive:  The domain name. This is appended to records that are not qualified (do not have a domain name) in order to create fully qualified names. In this example, if a name for a server is production01 then the fully qualified name will be production01.petervtamas.com.

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. The @ symbol will equal the $ORIGIN directive which in this example is petervtamas.com. If the $ORIGIN directive is not set, the @ symbol will equal the zone’s name.

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).

The NS records set dns1.petervtamas.com and dns2.petervtamas.com as the authoritative name servers.

Note that dns1.petervtamas.com and dns2.petervtamas.com have a dot at the end in the NS records while they do not in the A records. The dot indicates that this is the FQN (Fully Qualified Name). In those cases where the dot does not appear, the domain is added at the end. This is the value of $ORIGIN. Leaving off or adding the dot at the wrong time is an easy mistake to make. Here are some examples:
dns1 -> dns1.petervtamas.com
dns1. -> dns1
dns1.petervtamas.com. -> dns1.petervtamas.com
dns1.petervtamas.com -> dns1.petervtamas.com.petervtamas.com.

The Address record (usually called “the A Record”) specifies an IP address to be assigned to a name and follows the following form:
hostname  IN  A      ip-address

The IN indicates the class, which in this example is the Internet system. The other possible classes are rarely used.

The following lines are the A records that set the IP addresses for DNS1 and DNS2.
dns1      IN  A
dns2      IN  A

The MX records indicate that mail1.petervtamas.com and mail2.petervtamas.com are the mail servers. As with the NS records, the A records associated with the MX records appear immediately afterwards.

The MX record includes a preference-value, which is 10 and 20 in this example. The value indicates the mail exchanger’s priority and must be an unsigned 16-bit number (between 0 and 65535). The mail exchanger with the lower number is given preference. If delivery fails, it tries the one with the next lowest preference value. The actual values do not matter, just the order of the values. Usually the values are 10 apart to allow adding incremental values in the future.

If the hostname value is omitted, the record will point to the last specified hostname. In the example, requests for services.petervtamas.com are pointed to or
For example:
services  IN  A
                 IN  A

The CNAME record maps an alias to its canonical name. In this case, ftp is the alias and services.petervtamas.com is the canonical name. Note that an alias should never be in the right side of a record. Only canonical names should be used on the right side. For example, it may be tempting to use the alias in an NS record or MX record, particularly if the canonical name does not include “dns” or “mail” in the name but the alias does.

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 DNS file

$ORIGIN petervtamas.com.
$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.
          IN  NS     dns2.petervtamas.com.
dns1      IN  A
dns2      IN  A
@         IN  MX     10  mail1.petervtamas.com.
          IN  MX     20  mail2.petervtamas.com.
mail1     IN  A
mail2     IN  A
services  IN  A
          IN  A

ftp       IN  CNAME  services.petervtamas.com.

Add this zone statement to /etc/named.conf

zone "petervtamas.com" IN {
  type master;
  file "db.petervtamas.com";
  allow-update { none; };

Seconds Converted to Human Readable Units
Early versions of BIND only used seconds for time units, here is a conversion to values that are more easily read by humans.

Seconds       Other Time Units
60                      1M
1800                30M
3600                1H
10800             3H
21600             6H
43200             12H
86400              1D
259200            3D
604800            1W
31536000      365D
Tech Articles
Zone Files 2