The SOA record’s job
A Start of Authority (SOA) record is part of every DNS zone. It identifies the zone’s administrative starting point and provides values that DNS servers can use when coordinating copies of that zone. A zone is the portion of the DNS namespace served as a unit by a set of authoritative name servers. It might cover a whole domain, or a subdomain that has been delegated separately.
The SOA record belongs at the zone’s apex, often shown as the domain name itself. It is not a substitute for an A or AAAA record that points a hostname to an address, an MX record that directs email, or an NS record that lists authoritative name servers. Reading it is useful when you want to understand how a zone is organized or investigate why changes are not appearing consistently.
Reading the names and serial number
An SOA record begins with two names. The first, often called MNAME, identifies the server designated as the primary source for the zone in the record. The second, RNAME, is a contact address written in DNS name format: the first dot generally represents the @ in an email address. For example, hostmaster.example.test. represents hostmaster@example.test. This contact is not the domain’s MX destination and should not be read as an email-routing instruction.
Next comes the serial number, which identifies a version of the zone. When a zone changes, its serial should change so secondary servers can recognize that a newer copy is available. Some operators use a date-like numbering scheme; others use a simple incrementing number. The particular format matters less than updating it correctly within the system managing the zone. Serial comparisons also have wraparound rules, so a numerically larger value is not always the right way to decide which version is newer.
What the timers control
The SOA record also contains refresh, retry and expire values, conventionally expressed in seconds. Refresh tells a secondary server how long to wait between checks for a newer zone version. If a check fails, retry sets the interval before another attempt. Expire sets a limit on how long a secondary can continue serving its copy without successfully checking the source. These values describe behavior for secondary zone maintenance; they are not a schedule promising when every visitor will see a website change.
The final SOA field is called minimum. In modern DNS use, it helps set the caching period for negative answers, such as a response saying that a name does not exist. The SOA record has its own TTL as well. For a negative response, the effective TTL is based on the lower of the SOA TTL and minimum value, though resolver behavior and local limits can affect what you observe. Neither value replaces the TTLs on ordinary records such as A, AAAA or MX.
A small example
Consider this illustrative record, shown on one line: example.test. 3600 IN SOA ns1.example.test. hostmaster.example.test. ( 42 7200 900 1209600 300 ). The zone is example.test.; the SOA record’s TTL is 3600 seconds. It names ns1.example.test. as the designated primary source and encodes hostmaster@example.test as the contact. Its serial number is 42. The refresh, retry and expire values are 7200, 900 and 1209600 seconds, respectively, and its minimum value is 300 seconds.
This example does not tell you whether ns1.example.test. is publicly reachable, whether the contact mailbox is monitored, or which record answers a request for www.example.test. Those require separate checks. Likewise, a DNS provider may manage the underlying primary and secondary arrangements for you, so the SOA fields may reflect the provider’s setup rather than servers you operate directly.
Using the SOA record when troubleshooting
If two authoritative servers appear to give different answers for the same zone, compare their SOA serials along with the records you are investigating. Different serials can be a clue that a secondary has not obtained the latest zone. Check whether the zone is being edited at its intended source and whether transfer or update arrangements are working. Matching serials do not, by themselves, prove that every answer is identical.
Keep authoritative answers separate from cached answers when diagnosing a delay. A recursive resolver may still hold an earlier positive or negative response even after authoritative servers agree. Also confirm that you are querying the intended zone: a delegated subdomain has its own SOA, while an undelegated name falls within its parent zone. The SOA record gives valuable context, but it works best alongside checks of delegation, authoritative servers and the specific record in question.
