Technical Library

Domain Name System

Introduction

Integration

The first entry in each of the zone files is the Start of Authority (SOA) resource record. The SOA record indicates the authoritative name server for this domain. Since the SOA record marks the beginning of a zone, there can be only one for each zone.

The format of the SOA record is:

zone IN SOA origin contact (

    serial
    refresh
    retry
    expire
    minimum/time to live

)

The components of the SOA record are described below.

zone

This is the name of the zone. Usually, this SOA field contains an at-sign (@). When this symbol is used in an SOA record, it refers back to the domain name declared in the named.boot primary statement that points to this zone file.

IN

IN states the address class is the Internet class.

SOA

The type of resource record is SOA. All the information that follows this is part of the data field and complies to the SOA record.

origin

This is the host name of the primary name server for this domain, and normally written in the fully qualified domain name format (with a trailing dot).

contact

This is the e-mail address of the person responsible for this domain. However, the at-sign(@) in the e-mail address is replaced by a dot.

serial

This number can be considered to be the version number of the zone file. It may be a time stamp with the year, month, day, and the number of additional daily changes together as one number. For instance, 1995080701, would represent the first update to this file on August 7, 1995.

You must change the serial number every time you update the zone data. This field is used by secondary name servers to determine if the zone file on the primary server has been updated.

The secondary server requests the SOA record from the primary, and compares the serial number received to the serial number in its cache. If the serial number received from the primary has increased, the secondary server requests a full zone transfer. Otherwise, the secondary server assumes it has the most current zone data.

refresh

This is the length of time (in seconds) that the secondary name server should wait before checking with the primary server to see if the zone data has been modified.

A low refresh time keeps the secondary server's data closely behind the primary's, but a very low refresh time is not usually needed. A very low value can place an unnecessary burden on the network, as well as the secondary name server. The value used should reflect how often your domain database is updated.

retry

When a secondary name server requests a zone refresh, and the primary server fails to respond, the secondary name server should wait a given amount of time before retrying. The retry time is the amount of time (in seconds) that the secondary name server should wait before attempting another zone refresh after the failed attempt. This value should not be set too low.

Quickly retrying a down system costs network resources, and cause problems for secondary name servers that back up a large number of zones. Using one hour (3600) is safe and avoids retry loops.

expire

This defines how long (in seconds) the secondary name server should keep the data without receiving a zone refresh. If there has been no answer from the primary server to refresh requests after repeated retries for the amount of time specified in the expire, the secondary should discard its data.

minimum/time to live

This is the amount of time (in seconds) resource records from this zone should be held in a remote host's cache. It is recommended that this value be large. Making this value short will only force remote servers to query again for unchanged data. This value is also abbreviated as "ttl".