DNS zone file explained

Information below are extracted from http://www.ripe.net/docs/ripe-203.html∞

Remarks and Explanation

The values presented in the example.com SOA RR are discussed in detail. One main goal was to provide for fixed cut-and-paste values wherever possible instead of intervals to reduce the chance of operational problems caused by unfortunate combinations. Other values or sets of values will work as well, this is one set of values which reflects successful current practice with respect to scalability and stability.

The MNAME Value

The DNS specification explicitly states that the primary master server be named here. The value must be determined and used. Especially it is a mistake to repeat the zone name here, unless this also leads to a valid address of the primary master.

The RNAME Value

The RNAME is to publish a mail address of a person or role account dealing with this zone with the "@" converted to a ".". The best practice is to define (and maintain) a dedicated mail alias "hostmaster" [RFC 2142] for DNS operations.

The Serial Number

The most important issue is that this value be incremented after any modification to the zone data. For debugging purposes it has shown to be helpful to encode the modification date into the serial number. The value "1999022301" so is an example of the YYYYMMDDnn scheme and must be replaced by proper values for the year (YYYY, four digits), month (MM, two digits), day of month (DD, two digits) and version per day (nn, two digits). The first version of the day should have the value "01". It is important to preserve the order year - month - day. People using this as a debugging aid must, however, not rely on the date information, since experience shows that after initial setup maintainance of this value is often left to the auto-increment feature the software sometimes provides. Other schemes exist - documentation of which is out of the scope of this document.

The Refresh and Retry Values

The refresh and retry values primarily affect the zone maintainer and the secondary service providers and may be negotiated between them. The values chosen here are aimed at scalability. Modern DNS software implements NOTIFY [RFC 1996] and reduces the need for frequent SOA checks, as does the assumption of stability of the zone. While lower values would only slightly increase the bandwidth usage, they would increase the load on servers which are slaves for thousands of zones.

The Expire Value

The primary goal is to ensure stability of the zone data, even if a mistake invalidating (non-authorising) the zone or a network outage last for several days. A value of a week or two has proven to be way too short, so a longer time must be used. The specific value was chosen for aesthetic and historic reasons and to disambiguate between the different proposed values of "long".

The Minimum TTL Value

There are two meanings for this value with practical relevance. First, it serves as a default value for the TTL of all RRs without a given value. To be cache-friendly this value was chosen to be two days, which also follows the stability assumption. The second meaning is the default negative TTL [RFC 2308], which would call for a lower value. We are in a transition phase now with software implementing either of both meanings, so the TTL of one hour is recommended for the SOA itself, which will lead to nearly the same effect.
5. Security Considerations
Filling in the recommended values will not directly influence security of the name servers for the particular zone, any system with a name in that zone or any other system in the Internet. However, following these guidelines will likely contribute to DNS stability and thus to reachability. Maintaining proper contact information in the SOA RNAME field helps people in reporting problems, although the address distributed there is not recommended as a primary security contact.