A SOA record describes the authority of a DNS zone. It indicates the primary authoritative server and the contact address. It provides a serial number as well as timing values for secondary server synchronization.
A SOA record contains a name, a type, a primary server, a contact, a serial number and five durations. The TTL indicates how long the response remains cached in the local resolver.
| Name | Type | Primary Server MNAME | Contact RNAME | Serial | Refresh | Retry | Expire | Minimum TTL | TTL in seconds |
|---|
| @ | SOA | ns1.example.net. | hostmaster.example.com. | 2025090301 | 7200 | 900 | 1209600 | 3600 | 3600 |
In this example, the name @ targets the zone apex. The primary server must resolve to A or AAAA. The contact is written like an email address with a dot instead of the at sign. For example, hostmaster.example.com corresponds to hostmaster@example.com. The serial progresses with each zone modification. The refresh, retry, expire and minimum TTL values are in seconds.
The primary server MNAME designates the reference host for the zone.
The contact RNAME receives messages related to the zone.
The serial allows secondaries to know if a more recent version exists.
Refresh indicates when a secondary checks the primary.
Retry indicates the wait time between two attempts after a failure.
Expire indicates after how long a secondary abandons a zone that has become impossible to update.
Minimum TTL serves negative caching. It sets the duration during which an absence of response remains cached. The default TTL of records is set elsewhere in the zone.
Good to know
There is only one SOA per zone. It is published at the apex alongside NS records. The minimum TTL field does not define the default TTL of other records. It serves negative caching.
The SOA's TTL controls the cache duration of the SOA response on the resolver side. A TTL that is too long can delay the recognition of a serial change. A reasonable TTL improves responsiveness without overloading authoritative servers.
At the zone apex. Always. Delegated subdomains have their own SOA in their dedicated zone. A CNAME must not appear at the apex because the zone must already publish SOA and NS.
To avoid
Forgetting to increase the serial after a zone modification.
Setting a primary server that doesn't resolve to A or AAAA.
Inverting refresh and retry.
Using an expire that is too short which causes the zone to drop at secondaries.
An online DNS lookup allows you to enter a domain name. The result displays the SOA as it is seen from the Internet. You can read the primary server, the contact, the serial and the timing values. Then perform a local test from your machine.
Windows provides nslookup. You can use it in interactive mode.
nslookup
set q=soa
example.com
nslookup
set q=soa
server 1.1.1.1
example.com
The first part queries, according to the machine's network configuration. The second forces the use of a third-party resolver, here Cloudflare's.
On these systems, the dig command is practical and easy to use.
dig SOA example.com
dig SOA example.com @1.1.1.1
An older serial on a secondary server indicates a transfer delay.
A very long refresh delays the propagation of changes.
An expire that is too short can cause a secondary to abandon the zone.
A malformed contact prevents receiving useful messages.
- Prepare the zone update.
- Increase the serial.
- Reload the zone on the primary server.
- Let the secondaries update or trigger a transfer if the tool allows it.
- Check the new serial from several networks then validate.
Practical tip
Adopt a predictable serial format. A date format followed by a counter facilitates tracking. For example, 2025090301 for the first modification of the day.
Set up the zone on the new service. Check SOA and NS. Switch delegation when everything is ready.
Allow zone transfer on the primary. Check that the secondary properly retrieves the zone and displays the correct serial.
Update RNAME. Test that messages reach the correct recipient.
- If the SOA differs according to authoritative servers, wait for a refresh cycle then check again.
- If a secondary remains stuck on an old serial, check network access and zone transfer rights.
- If the zone disappears at a secondary, increase expire and check the primary's health.
- If the response remains old despite the update, wait for TTL expiration and purge the local resolver cache if possible.
In summary, a SOA record defines the authority of a zone. It indicates the primary server, the contact, the serial and the timing values that regulate synchronization. Only one SOA at the apex. Consistent values ensure reliable propagation. Verification goes through an online tool, then through nslookup and dig.
With these references, management remains clear. Changes proceed without stress. DNS services respond as expected.