Guide to reverse zones
Table of contents
1. Create a reverse zone
1.1 Start of Authority (SOA) record
1.2 Nameserver (NS) records
1.3 Pointer records
2. Nameserver software
3. Using BIND 9 to set up a primary nameserver for a zone
4. Using BIND 9 to set up a secondary nameserver for a zone
1. Creating a reverse zone
Creating a reverse zone is the same as creating any other zone file. The SOA and initial NS records are the same as any normal zone. However, you will need to create additional PTR records. The following information is based on creating reverse zones
using BIND. The principles should be the same for other DNS software; however, the details are likely to be different. If you are not using BIND, please see the documentation for the software package you are using.
1.1 Start of Authority (SOA) record
The SOA record is the first record in a properly configured zone. It contains information about the zone in a string of fields. An SOA record tells the server to be authoritative for the zone. The SOA record takes the format:
Example:
<domain.name.> IN SOA <hostname.domain.name.> |
<mailbox.domain.name> <serial-number> <refresh> <retry> <expire> <minimum-ttl> |
Where:
Field | Description | ||||||
---|---|---|---|---|---|---|---|
domain.name |
The name of the domain to which the SOA belongs. Instead of writing out the full domain, you can also use ‘@’ in the file to let the nameserver fill this out automatically. Example:
28.12.202.in-addr.arpa @ |
||||||
IN | The class of the DNS record. ‘IN’ is an abbreviated form of ‘Internet’. | ||||||
SOA | The type of DNS record, which in this case is ‘Start of Authority’. | ||||||
hostname.domain.name. | Also known as the ‘hostmaster’ field. It contains the e-mail address of the person responsible for maintaining the zone. No ‘@’ is used as this field was originally formatted as if it was a hostname (in which ‘@’ was invalid). The ‘@’ symbol is replaced by a ‘.’, and any ‘.’ before the “@” was replaced by ‘\’. Examples:
Recently, arbitrary characters have been permitted in this field, so ‘@’ can now be used. However, the old format is still used by the majority of hostmasters and it is assumed by many DNS validators. |
||||||
serial-number | The serial number of the current version of the DNS database for this domain. If a secondary server’s number is lower than the number of the primary server, it indicates that the secondary server’s records are out of date and that it requires a zone transfer from the primary server. |
||||||
refresh | This tells a secondary server how often to poll the primary server and check for changes in the serial number field. Measured in seconds. | ||||||
retry | If a refresh attempt fails, a secondary server will retry after the interval specified in the retry field. Measured in seconds. | ||||||
expire | If the refresh and retry attempts fail, the secondary server will stop serving the zone after the period specified in the expire field. Measured in seconds. | ||||||
minimum-ttl | The default TTL (Time To Live) for every record in the zone. The default is only used when a particular resource record does not have its own specified TTL value. When changes are being made to a zone, the default is often set at ten minutes or less. |
Example:
28.12.202.in-addr.arpa. IN SOA ns.apnic.net. |
dns-admin.apnic.net. ( 1999040701 ;Serial number 10800 ;Refresh 3600 ;Retry 604800 ;Expire 86400) ;Minimum TTL |
The ‘;’ character in the example above indicates that the rest of the line is a comment that should be ignored by the nameserver. Also note the trailing dot (‘.’) after each record referring to a hostname. Without the dot, the nameserver appends the current
zone after the record. For example, ns.apnic.net would be interpreted as ns.apnic.net.28.12.202.in-addr.arpa.
1.2 Nameserver (NS) records
An NS record declares the nameservers that serve a given zone. The NS record takes the format:
Example:
<domain.name.> IN NS <hostname.domain.name.> |
Where:
Field | Description |
---|---|
domain.name |
The name of the domain to which the NS belongs. Instead of writing out the full domain, you can also use ‘@’ in the file to let the nameserver fill this out automatically. Example:
28.12.202.in-addr.arpa @ [space] |
IN |
The class of the DNS record. ‘IN’ is an abbreviated form of ‘Internet’. |
NS |
The type of DNS record, which in this case is ‘Name Server’. |
hostname.domain.name. |
The hostname of an authoritative server. |
Example:
IN |
NS |
ns.apnic.net. |
IN |
NS |
svc00.apnic.net. |
IN |
NS |
ns.telstra.net. |
IN |
NS |
rs.arin.net. |
1.3 Pointer (PTR) records
Within the zone, you then need to create domain pointer (PTR) records for each IP address. For the address ‘202.12.28.131’, this would be:
131.28.12.202.in-addr.arpa. IN PTR svc00.apnic.net. |
However, as the SOA record for the zone already states the in-addr.arpa domain in full, you do not need to write this out again. Instead, you need only to write the last dotted quad from the address. Therefore, the above PTR entry can also be written
as follows:
131 IN PTR svc00.apnic.net. |
Once you have created all the relevant PTR records for your in-addr.arpa zone, the next step is to load it onto your nameserver.
2. Nameserver software
There are various implementations of DNS protocols. The most popular is BIND.
Berkeley Internet Name Domain (BIND) |
BIND is currently available in two versions: BIND 8 and BIND 9. APNIC recommends that you install BIND 9 as this version has more features and security fixes than BIND 8. Information is available on the latest version of Bind at ISC Bind A list of other nameserver software is available at Comparison of DNS server software |
3. Using BIND 9 to set up the primary nameserver for a zone
1. Add an entry specifying the primary server to the named.conf file using the following format:
zone "<domain-name>" in { type master; file "<path-name>"; }; |
Where:
Field | Description |
---|---|
domain.name |
The name of the domain. Example:
28.12.202.in-addr.arpa |
type master |
Defines this nameserver as the primary nameserver for <domain-name>. |
path-name |
The location of the file that contains the zone records. The name of the file is entirely arbitrary. What you may choose to name the file has no relationship to the name of the zone which is being made primary. If you have a large site, consider using the ‘include‘ command to avoid an excessively large named.conf: |
2. Tell the nameserver to read in the new zone file by executing the command:
rndc reconfig |
Example Primary Nameserver:
zone "28.12.202.in-addr.arpa" in { type master; file "reverse/28.12.202.in-addr.arpa"; }; |
4. Using BIND 9 to set up a secondary nameserver for a zone
1. Add an entry specifying the secondary server to the named.conf file using the following format:
zone "<domain-name>" type slave; file "path-name"; masters { <ip-address>; }; }; |
Where:
Field | Description |
---|---|
domain.name |
The name of the domain. Example:
28.12.202.in-addr.arpa |
type slave |
Defines this server as a secondary nameserver. |
path-name |
The location of the file that contains the zone records. The name of the file is entirely arbitrary. What you may choose to name the file has no relationship to the name of the zone which is being made secondary. |
2. Tell the nameserver to reconfigure using the command:
rndc reconfig |
Example:
zone "28.12.202.in-addr.arpa" in { type slave; file "slave/28.12.202.in-addr.arpa"; masters { 203.37.255.97; }; }; |
More information
- RFC 1537 – Common DNS Data File Configuration Errors
- DNS Resource Records by Cisco