Hubbry Logo
SOA recordSOA recordMain
Open search
SOA record
Community hub
SOA record
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
SOA record
SOA record
SOA record
View on Wikipedia
from Wikipedia

A start of authority record (abbreviated as SOA record) is a type of resource record in the Domain Name System (DNS) containing administrative information about the zone, especially regarding zone transfers. The SOA record format is specified in RFC 1035.[1]

Background

[edit]

Normally DNS name servers are set up in clusters. The database within each cluster is synchronized through zone transfers. The SOA record for a zone contains data to control the zone transfer. This is the serial number and different timespans.

It also contains the email address of the responsible person for this zone, as well as the name of the primary master name server. Usually the SOA record is located at the top of the zone. A zone without a SOA record does not conform to the standard required by RFC 1035.

Structure

[edit]
NAME
Name of the zone. @ refers to the $ORIGIN (often the apex) in BIND syntax.
CLASS
Zone class (all but universally IN for Internet)
TYPE
SOA, abbreviation for start of authority
TTL
Time-to-live
MNAME
Primary master name server for this zone
RNAME
Email address of the administrator responsible for this zone. (As usual, the email address is encoded as a name. The part of the email address before the @ becomes the first label of the name; the domain name after the @ becomes the rest of the name. In zone-file format, dots in labels are escaped with backslashes; thus the email address john.doe@example.com would be represented in a zone file as john\.doe.example.com.)
SERIAL
Serial number for this zone. If a secondary name server slaved to this one observes an increase in this number, the slave will assume that the zone has been updated and initiate a zone transfer.
REFRESH
Number of seconds after which secondary name servers should query the master for the SOA record, to detect zone changes. Recommendation for small and stable zones:[4] 86400 seconds (24 hours).
RETRY
Number of seconds after which secondary name servers should retry to request the serial number from the master if the master does not respond. It must be less than Refresh. Recommendation for small and stable zones:[4] 7200 seconds (2 hours).
EXPIRE
Number of seconds after which secondary name servers should stop answering requests for this zone if the master does not respond. This value must be bigger than the sum of Refresh and Retry. Recommendation for small and stable zones:[4] 3600000 seconds (1000 hours).
MINIMUM
Used in calculating the time to live for purposes of negative caching. Authoritative name servers take the smaller of the SOA TTL and the SOA MINIMUM to send as the SOA TTL in negative responses. Resolvers use the resulting SOA TTL to understand for how long they are allowed to cache a negative response. Recommendation for small and stable zones:[4] 172800 seconds (2 days). Originally this field had the meaning of a minimum TTL value for resource records in this zone; it was changed to its current meaning by RFC 2308.[5]

Sample SOA record

[edit]

Sample SOA record for example.org, in BIND syntax. 

$TTL 86400
@   IN  SOA     ns.icann.org. noc.dns.icann.org. (
        2020080302  ;Serial
        7200        ;Refresh
        3600        ;Retry
        1209600     ;Expire
        3600        ;Negative response caching TTL
)

Serial number changes

[edit]
Main article: Serial number arithmetic

Several methods have been established for updates to the SERIAL field of a zone's SOA record:

  • The serial number begins at 1, and is simply incremented at every change.
  • The serial number contains the date of the last change (in ISO 8601 basic format) followed by a two-digit counter. For example, the fifth change made on 14 March 2017 (2017-03-14 in ISO 8601) would have the serial number 2017031404. This method is recommended in RFC 1912.[6]
  • The serial number is the time of last modification to the zone's data file expressed as the number of seconds since the UNIX epoch. This method is used by default in the djbdns suite.[7] Although it uses a 32-bit counter, it is not susceptible to the year 2038 problem due to the effect of serial number arithmetic.

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

SOA record

View on Grokipedia
from Grokipedia
The Start of Authority (SOA) record is a fundamental resource record type in the (DNS) that marks the beginning of a zone of authority, providing essential administrative and operational information about the DNS zone it governs. Defined in the original DNS specifications, the SOA record specifies the primary responsible for the zone, the contact for the zone administrator (encoded as a domain name without the "@" symbol), a indicating the zone's version, and several timing parameters that control how secondary name servers synchronize and maintain the zone data. It is mandatory for every DNS to begin with exactly one SOA record, ensuring consistent authority delegation and data freshness across the distributed DNS infrastructure. The structure of an SOA record consists of seven fixed fields, each serving a precise role in zone management:
FieldDescriptionData Type
MNAMEThe domain name of the primary (source) name server for the zone.Domain name
RNAMEThe domain name representing the email address of the zone administrator (e.g., "admin.example.com" for [email protected]).Domain name
SERIALAn unsigned 32-bit integer tracking the zone's revision; increments with changes to trigger updates.Unsigned 32-bit integer
REFRESHThe time interval (in seconds) at which secondary servers should check for zone updates from the primary.Unsigned 32-bit integer
RETRYThe time interval (in seconds) before a secondary server retries a failed refresh attempt.Unsigned 32-bit integer
EXPIREThe time (in seconds) after which a secondary server considers the zone data invalid if it cannot contact the primary.Unsigned 32-bit integer
MINIMUMThe default Time to Live (TTL) value (in seconds) applied as a floor to other resource records in the zone when responding to queries.Unsigned 32-bit integer
These fields enable efficient zone transfers (AXFR or IXFR) over TCP, where the SOA record is transmitted first to verify compatibility and serial numbers. In practice, the SOA record plays a critical role in DNS operations beyond mere identification: it facilitates fault-tolerant replication by dictating refresh cycles (typically 24 hours or 86400 seconds), retry intervals (often 1-2 hours), and expiration thresholds (commonly 1-2 weeks) to prevent outdated or stale zone data from propagating errors. When a zone's changes—due to additions, deletions, or modifications of other records—secondary servers detect this during their refresh polls and initiate transfers to stay synchronized. Additionally, the MINIMUM field helps optimize caching by setting a baseline TTL, reducing unnecessary queries while adhering to IETF standards for DNS reliability and scalability. Introduced in 1987 as part of the core DNS protocol, the SOA record remains indispensable for authoritative DNS servers worldwide, underpinning the stability of domain resolution.

Introduction

Definition and Purpose

The Start of Authority (SOA) record is a type of (DNS) resource record with type code 6 that must exist exactly once per , marking the beginning of the zone's authoritative data and defining the scope of administrative control for that domain. As the foundational record in a , it declares the zone's within the DNS , serving as the of the zone's and informing resolvers and secondary servers about the boundaries of authoritative information for the domain. The primary purpose of the SOA record is to specify the primary responsible for the zone, provide contact information for the domain administrator, and include parameters that enable secondary servers to perform zone transfers and manage caching effectively. This configuration ensures coordinated maintenance across distributed DNS infrastructure, allowing secondary servers to synchronize data from the primary source while adhering to defined refresh and expiration guidelines. In DNS operations, the SOA record supports zone transfers by providing parameters for synchronization between primary and secondary servers, and its MINIMUM field sets the default TTL for negative caching responses, including NXDOMAIN, as clarified in RFC 2308. It declares the zone's authority but does not enforce update authorization. Unlike NS records, which simply identify the name servers hosting the zone, the SOA record supplies the essential administrative details needed for operational integrity.

Historical Development

The Start of Authority (SOA) record was introduced in 1987 as a fundamental component of the (DNS) specification outlined in RFC 1035, authored by . This record type emerged as part of the effort to establish a hierarchical, distributed naming for the , supplanting earlier centralized approaches like the hosts.txt file maintained by the Stanford Research Institute for the . The SOA record was designed to hold administrative and authoritative information for a , marking the beginning of standardized mechanisms for managing domain data across a growing network. In its early conception, the SOA record addressed the need for decentralized administration during the ARPANET's evolution into a more robust infrastructure. By enabling zone administrators to specify contact details, version tracking, and timing parameters, it facilitated the transition from monolithic host tables to a federated where multiple entities could independently manage portions of the . This was crucial in the late , as the network expanded beyond academic and military use, requiring reliable methods for propagating updates without central bottlenecks. Subsequent refinements clarified and extended the SOA record's functionality through targeted RFC updates. RFC 1982, published in 1996, provided precise rules for arithmetic to prevent issues in zone transfer comparisons, ensuring consistent versioning across resolvers. In 1998, RFC 2308 redefined the MINIMUM field to serve as the (TTL) for negative caching, improving efficiency in handling non-existent domain queries. In 2019, RFC 8499 incorporated the SOA record into an updated DNS glossary. In November 2024, RFC 9499 further updated the DNS , affirming its enduring role in protocol documentation. The SOA record gained widespread adoption in the late 1980s through its integration into the Berkeley Name Domain () software, the first widely deployed DNS implementation, which became the for servers. This timeline was driven by the 's rapid growth, necessitating dependable zone transfer protocols to maintain data consistency amid increasing domain registrations and inter-domain communications.

Record Structure

Field Components

The SOA record consists of seven fields defined in the Resource Record Data (RDATA) portion, which collectively provide administrative and operational parameters for a DNS zone. These fields are represented in the DNS master file format, where domain names are subject to standard compression techniques to optimize storage and transmission, and all time intervals are expressed in seconds as 32-bit unsigned integers unless otherwise specified. The fields must be present in every SOA record, with MNAME and RNAME as required domain names, and the remaining five as numeric values essential for zone synchronization and caching. The first field, MNAME, specifies the hostname of the primary responsible for the zone, serving as the authoritative source for zone data updates and transfers. It is encoded as a standard and must resolve to a valid name server address within the DNS . The second field, RNAME, identifies the of the zone administrator in a domain name format, where the "@" symbol is replaced by a dot (e.g., "hostmaster.example.com" corresponds to [email protected]). This field functions as the contact point for administrative issues related to the zone, also encoded as a compressed . The third field, SERIAL, is a 32-bit unsigned representing the version number of the , incremented by the primary server whenever changes occur to detect updates during transfers. It supports arithmetic to handle wrap-around from its maximum value of 4294967295, ensuring reliable change tracking without gaps. The fourth field, REFRESH, defines the suggested time interval at which secondary name servers should check the primary for zone updates, typically ranging from 1200 seconds (20 minutes) to 43200 seconds (12 hours) depending on update frequency. This 32-bit unsigned promotes efficient while minimizing unnecessary queries. The fifth field, RETRY, specifies the time interval a secondary server should wait before retrying a failed refresh attempt, often set as a of REFRESH, such as 1200 to 7200 seconds (20 minutes to 2 hours). As a 32-bit unsigned , it ensures resilience against temporary connectivity issues without overwhelming the primary server. The sixth field, EXPIRE, indicates the maximum duration a secondary server can continue serving zone as authoritative after failing to contact the primary, commonly configured between 1209600 and 2419200 seconds (14 to 28 days) to balance availability and data staleness. This 32-bit unsigned value must exceed the REFRESH interval to prevent premature invalidation during outages. The seventh field, MINIMUM, establishes the default time-to-live (TTL) value applied to all resource records from the zone in query responses, as well as the TTL for negative caching of non-existent data, typically set between 86400 and 432000 seconds (1 to 5 days) for stable zones. Represented as a 32-bit unsigned integer in seconds, it acts as a floor for TTLs, overriding lower values in individual records to enforce consistent caching behavior.

Data Encoding and Constraints

The SOA record is encoded as a variable-length resource record with type 6 in DNS messages, typically within the (IN) class, consisting of two domain names followed by five 32-bit unsigned fields. The domain names for the primary (MNAME) and responsible person (RNAME) are represented in the standard DNS wire format, utilizing -based encoding where each is preceded by a 1-octet (0-63), followed by the label characters, and terminated by a zero- label; these names support pointer-based compression to reduce message size when the same name appears multiple elsewhere in the message. The fields— (SERIAL), refresh interval (REFRESH), retry interval (RETRY), expire limit (EXPIRE), and minimum TTL (MINIMUM)—are each encoded as 32-bit unsigned integers in network byte order (big-endian), representing time intervals in seconds, with no additional padding or null terminators between fields. The total RDATA varies depending on the encoded size of the domain names, which can range from 3 octets (for a single- name) up to 255 octets per name, resulting in a minimum SOA RDATA size of 26 octets and no fixed maximum beyond the overall DNS message limit of 65535 octets. For the RNAME field, the email address of the responsible person is transformed into a domain name format by replacing the "@" symbol with a dot; for example, "[email protected]" becomes the domain name "hostmaster.example.com", encoded as per the standard domain name rules without any special delimiters. This encoding ensures compatibility with the DNS protocol's domain name handling, treating the mailbox as a hierarchical name under the root. Serial number arithmetic operates modulo 2322^{32}, treating the SERIAL as an unsigned 32-bit where increments wrap around from 4294967295 to 0, and comparisons use rules to determine if one value is greater, less than, or equal to another, avoiding ambiguities in the circular space by limiting increments to at most 231−12^{31} - 1 within the expire interval. The time interval fields (REFRESH, RETRY, EXPIRE, MINIMUM) must be positive unsigned 32-bit values, with REFRESH recommended between 1200 and 43200 seconds, EXPIRE at least as large as REFRESH plus several retry attempts (typically 1209600 to 2419200 seconds), and MINIMUM between 86400 and 432000 seconds to balance caching efficiency; values outside these ranges may lead to operational issues like excessive polling or premature data expiration, though the protocol permits any value from 1 to 232−12^{32} - 1. Resolvers encountering fields, such as non-positive times or malformed domain names, typically discard the entire SOA record or response to prevent propagation of s, as specified in the DNS protocol's error handling. In zone files, the SOA record follows the master file syntax defined for and compatible implementations, presented as a single line or multi-line entry using parentheses to group the fields for readability: example.com. IN SOA ns1.example.com. hostmaster.example.com. ( SERIAL REFRESH RETRY EXPIRE MINIMUM ). The RNAME may be enclosed in double quotes if it contains spaces or special characters, though this is rare given the constraints, and all times are specified in seconds without units. This presentation format facilitates human editing while mapping directly to the binary wire encoding upon loading into a nameserver.

Usage and Examples

Sample SOA Record

A typical SOA record appears at the beginning of a DNS zone file for a domain, defining the authoritative parameters for that zone. The following example illustrates an SOA record for the hypothetical domain example.com, using standard conventions for field values as specified in the original DNS protocol documentation.

example.com. IN SOA ns1.example.com. hostmaster.example.com. ( 2025111001 ; Serial (YYYYMMDDNN format: November 10, 2025, revision 01) 3600 ; Refresh (1 hour) 1800 ; Retry (30 minutes) 604800 ; Expire (1 week) 86400 ; Minimum TTL (1 day) )

example.com. IN SOA ns1.example.com. hostmaster.example.com. ( 2025111001 ; Serial (YYYYMMDDNN format: November 10, 2025, revision 01) 3600 ; Refresh (1 hour) 1800 ; Retry (30 minutes) 604800 ; Expire (1 week) 86400 ; Minimum TTL (1 day) )

In this sample, the serial number employs the common YYYYMMDDNN format, where 2025111001 represents the date November 10, 2025, followed by a two-digit revision counter starting at 00; this approach facilitates incremental updates while maintaining a 32-bit unsigned integer limit. The refresh interval of 3600 seconds indicates how often secondary servers should check for updates, the retry value of 1800 seconds sets the wait time after a failed refresh attempt, the expire duration of 604800 seconds (one week) defines when secondaries discard the zone if unreachable, and the minimum TTL of 86400 seconds (one day) serves as the default caching time for negative responses unless overridden by individual resource records. This SOA record is positioned as the first entry in the zone file for example.com, with the domain origin implied by the @ symbol in many configurations, and it inherits or sets a default TTL for the zone unless a separate $TTL directive is used at the file's start. Variations in serial number formatting exist, such as using a simple incrementing integer or alternative date orders like DDMMYYYYNN in some legacy systems, though the YYYYMMDDNN convention remains widely recommended for clarity and automation compatibility.

Interpretation of Fields

In the sample SOA record for the example.com zone, the MNAME field specifies ns1.example.com as the primary , which serves as the target for secondary servers initiating zone transfers such as AXFR or IXFR requests. This designation ensures that updates are pulled from a designated authoritative source, facilitating consistent propagation of zone data across the DNS infrastructure. The RNAME field identifies the responsible party's email address, typically formatted as a domain name (e.g., hostmaster.example.com, equivalent to [email protected]), providing a direct contact point for troubleshooting zone-related issues or reporting errors. The SERIAL field, set to 2025111001, represents an unsigned 32-bit integer version number for the zone, where the value follows a common YYYYMMDDnn format to indicate the last modification date (November 10, 2025) and a two-digit revision sequence (01). This numbering scheme allows secondary servers to detect changes by comparing serial values during refresh checks, triggering transfers only when the primary's serial is higher. Operationally, the REFRESH interval of 3600 seconds (1 hour) dictates how frequently secondary servers should poll the primary for updates, promoting timely while avoiding excessive network load in stable environments. If a refresh fails, the RETRY value of 1800 seconds (30 minutes) enables rapid recovery attempts, minimizing from transient connectivity issues. The EXPIRE setting of 604800 seconds (7 days) establishes the maximum period a secondary can serve potentially stale data before considering the zone and ceasing responses, thereby preventing widespread dissemination of outdated information during prolonged primary outages. However, such a relatively short EXPIRE duration increases the risk of secondary servers expiring the zone prematurely, potentially causing resolver outages if the primary remains unreachable beyond this window. Best practices recommend balancing these timing intervals to optimize reliability against administrative overhead; for instance, shorter REFRESH and values enhance responsiveness in high-change zones but may strain server resources, while longer EXPIRE settings (e.g., 10-30 days) better tolerate outages without risking data invalidation. The MINIMUM field at 86400 seconds (1 day) primarily governs the TTL for negative caching responses (such as NXDOMAIN or NODATA), as defined in RFC 2308, instructing resolvers on how long to cache indications of non-existent records and reducing query volume to authoritative servers for non-existent names. This value influences resolver behavior by establishing a floor on how long negative answers persist in caches, aiding efficiency but requiring adjustment in dynamic environments to avoid prolonged caching of incorrect negatives.

Administrative Functions

Serial Number Management

The SERIAL field of the SOA record is a 32-bit unsigned integer representing the version number of the original copy of the zone. It functions as a counter that the primary name server increments to signal changes in the zone data to secondary servers. For minor modifications, such as adding a single resource record, the serial is typically increased by 1; for more significant updates, administrators may adopt a date-based value to clearly indicate the timing of the change. Serial number comparisons follow the rules outlined in RFC 1982, employing arithmetic modulo 2^32 to handle the finite range of 0 to 4294967295. A secondary server determines the need for a zone transfer by checking if its local SERIAL precedes the primary's SERIAL, using the defined ordering: one serial S1 precedes another S2 if (S1 < S2 and S2 - S1 < 2^{31}) or (S1 > S2 and S1 - S2 > 2^{31}). This ensures reliable detection of updates even across wrap-around points, with increments limited to less than 2^{31} to avoid ambiguous comparisons. To manage updates effectively and mitigate risks like prolonged sequential incrementing leading to overflow, a common strategy is the YYYYMMDDnn format, where YYYYMMDD denotes the date of modification (in four-digit year, two-digit month, and two-digit day) and nn is a sequence counter from 00 to 99. This method promotes orderly progression and aligns changes with timestamps, reducing the likelihood of errors in high-update environments. DNS software like BIND supports automation of these updates through the serial-update-method configuration option, which can be set to "increment" for simple +1 adjustments, "unixtime" for Unix timestamp values, or "date" to generate YYYYMMDD00 (or increment if the existing serial is higher). Tools such as BIND's rndc facilitate this by enabling zone reloads and DNSSEC re-signing without manual intervention, ensuring the serial advances only when necessary. Challenges in serial management include handling overflow, where the value reaches 4294967295 and subsequent increments wrap to 0 via modulo 2^32; the arithmetic rules preserve update detection provided increments remain under 2^{31}. Resetting to a low value like 1 after nearing the maximum requires caution, as it may result in incomparable ordering under RFC 1982's rules, preventing secondaries from recognizing the update and triggering transfers—in such cases, incrementing from the current value or switching to a date format is preferred. Serial mismatches between servers often signal stale zones, enabling administrators to diagnose synchronization failures by verifying SERIAL consistency across the replication topology. To minimize issues, increments should be avoided for unchanged zones, a practice enforced through careful manual editing or automated validation in management tools.

Timing Intervals and Zone Transfers

The REFRESH interval in the SOA record specifies the duration after which secondary DNS servers should poll the primary server to check for zone updates, typically measured in seconds and representing the expected time between successful transfers. This polling mechanism ensures that secondaries maintain synchronization with the primary by querying the SOA at the defined frequency. The RETRY interval defines the time secondary servers wait before attempting another transfer request following a failed poll, serving as a backoff period to avoid overwhelming the primary during temporary outages. Meanwhile, the EXPIRE interval sets the maximum time a secondary can use its cached zone without successfully contacting the primary, after which the is considered to prevent serving stale information. The MINIMUM field, also known as the negative TTL, establishes the caching duration for negative responses such as NXDOMAIN or NODATA, helping resolvers avoid repeated queries for non-existent names and reducing network load. In the zone transfer process, secondary servers initiate polling of the primary at intervals governed by the REFRESH value; if the SOA serial number has increased, the secondary requests a full zone transfer via AXFR or an incremental update via IXFR to synchronize the zone content. Upon a failed transfer attempt, the secondary retries after the RETRY interval, continuing this loop until successful or until the cumulative time exceeds the EXPIRE threshold, at which point the secondary stops responding authoritatively for the zone. This failure handling promotes resilience while bounding the risk of prolonged desynchronization across the DNS infrastructure. Configuration guidelines for these intervals balance update freshness against server load and network stability. The REFRESH is commonly set between 1 and 24 hours to allow stable zones to update without excessive polling, though shorter values like 20 minutes may suit high-change environments. RETRY should be shorter than REFRESH, often such as 10-15 minutes, to enable prompt recovery from transient issues. EXPIRE values range from 7 to 30 days, ensuring secondaries do not serve outdated data indefinitely while accommodating extended outages. For MINIMUM, settings of 1 to 24 hours support efficient negative caching, aligning with the need to refresh non-existence information periodically without overburdening resolvers. The NOTIFY protocol complements these pull-based intervals by enabling primary servers to push notifications to secondaries upon zone changes, potentially triggering earlier transfers and reducing reliance on REFRESH polling. A common pitfall is configuring an overly short EXPIRE, which can lead to cascading failures where multiple secondaries simultaneously lose authority and flood the primary with transfer requests during recovery. Proper tuning of these intervals thus supports robust DNS operations across distributed authoritative servers.
Add your contribution
Related Hubs
User Avatar
No comments yet.