The SOA record, short for start of authority, is the one DNS record every zone must have. It names the primary nameserver and the admin mailbox, then carries five timers.
Four govern how a secondary server stays in step with the primary and are invisible to everyone else. The fifth, MINIMUM, sets how long a resolver caches the answer that a name does not exist, which since RFC 2308 is its only remaining job.
- Exactly one SOA record per zone, and the zone is invalid without it
- MNAME and RNAME name the primary server and the admin email
- SERIAL is the version number secondaries compare before transferring
- REFRESH, RETRY and EXPIRE only govern secondary to primary behavior
- MINIMUM is the negative caching TTL, and it is the one that bites
On this page
The shapeReading an SOA record
An SOA record has a fixed shape. Every field is positional, so the order is the meaning.
The same fields appear in every DNS zone, whatever software serves it.
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2026090901 ; SERIAL
7200 ; REFRESH
3600 ; RETRY
1209600 ; EXPIRE
3600 ) ; MINIMUMMNAME, here ns1.example.com., names the primary DNS server: the one holding the master copy of the zone data. Secondaries transfer from it, and dynamic updates are sent to it. It does not have to be a server listed in the zone's NS records, and when it is not, the term for it is a hidden primary.
RNAME, here hostmaster.example.com., is the administrative email mailbox with the at sign replaced by a dot, because the at sign is not legal in a domain name. That address reads as [email protected].
If the local part itself contains a dot, it is escaped, so first\.last.example.com. means [email protected]. Almost nobody reads email sent there, which is worth knowing before relying on it.
Then five numbers, all in seconds.
The timersThe five timers, and who each one is for
This is the part most explanations flatten, and the distinction is the whole point: four of the five timers are a conversation between two DNS servers, and one is a conversation with the entire internet.
SERIAL is the zone's version number. A secondary DNS server asks the primary for its SOA record, compares the serial number to its own, and transfers the zone data only if the primary is higher. Change a DNS record without changing the serial and secondaries will never notice.
The common convention is a date with a two digit counter, YYYYMMDDnn, which stays readable and stays ascending. Serial comparison uses sequence space arithmetic rather than plain integers, which is why a serial that wraps or is set backwards causes transfers to stop in ways that look like nothing is wrong.
REFRESH is how many seconds a secondary waits between polls of the primary SOA record to see whether the serial moved. It is the field that decides how much time can pass before an edit reaches the other DNS servers for the zone.
Most modern setups also use NOTIFY, where the primary DNS server tells secondaries immediately after a change, which makes REFRESH the fallback rather than the mechanism.
RETRY is how many seconds a secondary waits before trying again after a failed refresh. It should be shorter than REFRESH; a retry longer than the refresh interval is a configuration that never retries in any useful sense.
EXPIRE is the important one for resilience. If a secondary cannot reach the primary DNS server for this long, it stops answering for the zone at all. Not stale answers, no answers.
A short EXPIRE turns a primary server outage into an outage of the whole domain name even though the secondary DNS servers still hold a perfectly good copy of the zone. Two to four weeks is the usual range, and EXPIRE must be comfortably larger than REFRESH plus RETRY or a single bad afternoon can start the countdown.
MINIMUM is the outlier, and the next section is about it.
MINIMUMMINIMUM does not mean minimum
The field is named for a job it no longer does. In RFC 1035 the MINIMUM field was overloaded: the minimum TTL of every record in the DNS zone, the default TTL for records without one of their own, and the TTL for negative answers.
RFC 2308 kept only the last of those. MINIMUM is the negative caching TTL, and the other two meanings are gone.
Negative caching is what happens when a DNS resolver asks for a name in the domain that does not exist and gets NXDOMAIN back. Rather than ask the DNS servers again on every lookup, the resolver remembers the absence, and MINIMUM sets the length of time it remembers.
There is a subtlety that almost every summary drops. RFC 2308 says the TTL of that cached negative answer is taken from the minimum of the SOA MINIMUM field and the SOA record's own TTL. Both numbers apply, and the smaller one wins.
Setting MINIMUM to 300 while the SOA record itself carries a TTL of 86,400 gives you 300, and setting MINIMUM to 86,400 with an SOA TTL of 300 also gives you 300.
If you are trying to shorten negative caching before a migration, lowering one of the two and not the other does nothing.
The practical consequence is the reason this field matters more than the other four put together. Publish a DNS record with a typo in the name, and every resolver that looked it up before the fix caches the absence for MINIMUM seconds.
RFC 2308 is explicit about the range that works: values of one to three hours have been found to work well and make a sensible default, and values exceeding one day have been found to be problematic. A zone carrying a MINIMUM of 86,400 is a zone where a five minute mistake is a next day problem.
Two DNS zones served by the same software can carry very different values here, so read the one you are about to change rather than the one you changed last time.
ValuesSensible values, and the relationships between them
| Field | Common value | The rule that matters |
|---|---|---|
| SERIAL | YYYYMMDDnn | Must increase on every change |
| REFRESH | 3,600 to 86,400 | Mostly a fallback where NOTIFY works |
| RETRY | 600 to 3,600 | Shorter than REFRESH |
| EXPIRE | 1,209,600 to 2,419,200 | Greater than REFRESH plus RETRY, by a lot |
| MINIMUM | 3,600 to 10,800 | RFC 2308: over a day is problematic |
| SOA TTL | 3,600 | Caps MINIMUM for negative answers |
The three relationships are worth stating on their own, because a DNS zone validator will flag them and the reason is not obvious from the field names.
RETRY below REFRESH, because a secondary that has just failed should try again sooner than its normal schedule, not later.
EXPIRE far above REFRESH plus RETRY, because EXPIRE is a last resort and it should take a sustained outage rather than a couple of missed polls to reach it.
MINIMUM low, because the field's only remaining job is to decide how long a mistake outlives its fix.
Checking itHow to check an SOA record
The query is the same everywhere and takes a second.
dig SOA example.com +short
dig SOA example.com @ns1.example.com ; ask the primary directlyOn Windows, nslookup -type=soa example.com. Ask an authoritative DNS server rather than a resolver when you are debugging, because a resolver hands you a cached copy and the cached copy is often the thing you are trying to understand.
If the query itself never arrives, the problem is lower down: check the path to the server before blaming the zone.
Three checks are worth making a habit.
Compare the serial number across every DNS server. Query each name server in the NS set in turn. If the serials differ, a transfer has failed and the DNS servers are answering with different information.
That is the failure mode behind a great many reports that a change worked for some people and not others. It is also the first thing to check when DNS is not resolving consistently.
Check that MNAME is reachable and correct. A primary DNS server that no longer exists breaks dynamic updates and confuses tooling, and it is common after a name server migration.
Read the MINIMUM before a cutover. Lower it, and the SOA TTL with it, a day or two before a migration rather than on the day, because the old value is already cached.
PitfallsWhere SOA records go wrong
The serial that did not move. An edit that changes a DNS record but not the serial propagates to nothing. Automation that rewrites DNS zone files is the usual culprit, and the symptom is a change that is live on one server and invisible on the rest.
The serial that went backwards. Switching from a date based serial to a counter, or restoring a zone file from a backup, can produce a serial lower than the one secondaries already hold.
They will refuse to transfer and will keep serving old zone information indefinitely, without logging anything that looks like an error.
A MINIMUM measured in days. The single most common real cost of a badly written SOA. Nothing in normal operation reveals it; you find out during an incident, when the fix is live everywhere except in the caches that matter.
An EXPIRE that is too short. A week sounds prudent and is not.
It means a primary DNS server that stays down for eight days takes the entire domain offline even though every secondary DNS server still has a complete, valid copy of the zone.
Trusting the RNAME mailbox. It is a real email address in the record and usually not a real address in the mail system. If it is meant to receive abuse or expiry notices, send a test email to it before you need it.
Editing the SOA and forgetting the port. None of this reaches anyone if the servers are unreachable. DNS on port 53 has to be open for both UDP and TCP, and zone transfers in particular use TCP because the zone data outgrows what a UDP datagram will carry.
ComparisonSOA, NS, A and CNAME, on what each one is for
| Criterion | SOA | NS | A or AAAA | CNAME |
|---|---|---|---|---|
| Required in a zone | Yes, exactly one | Yes, at least one | No | No |
| What it names | The zone's authority and timers | The servers to ask | An address | Another name |
| Who consumes it | Secondaries and resolvers | Resolvers | Everyone | Everyone |
| Affects caching of absence | Yes, through MINIMUM | No | No | No |
| Changing it triggers a transfer | Yes, via SERIAL | Yes | Yes | Yes |
| Common failure | A serial that never moves | Delegation mismatch | Wrong address | Loops and apex misuse |
The second row is the useful summary. NS records say who is authoritative, and the SOA record says what being authoritative means in practice: which server holds the master copy, how the copies stay in step, and how long the world remembers a gap.
FAQFrequently asked questions
What is an SOA record?
The start of authority record, the mandatory record at the top of every DNS zone. It names the primary DNS name server and the admin email mailbox and carries five timers that govern zone transfers and negative caching.
What does SOA stand for in DNS?
Start of authority. It marks the beginning of a DNS zone's authoritative data and holds the parameters for that domain name. Every zone file opens with it, and the records that follow belong to the same zone until a delegation hands part of the name space to other DNS servers.
How many SOA records can a zone have?
Exactly one. A DNS zone without an SOA record is invalid, and a zone with two is a misconfiguration that most name servers will refuse to load. Managed DNS providers usually hide the record and keep the serial number moving for you.
What are the fields in an SOA record?
MNAME, the primary DNS name server. RNAME, the admin email mailbox with the at sign written as a dot. Then SERIAL, REFRESH, RETRY, EXPIRE and MINIMUM, all in seconds except the serial, which is a version number.
What does the SOA MINIMUM field actually do?
Since RFC 2308 it sets the negative caching TTL: how long a resolver remembers that a name does not exist. Its older meanings, the zone's minimum TTL and the default TTL, are deprecated.
Why is my NXDOMAIN cached for so long?
Because the negative cache TTL is the smaller of the SOA MINIMUM field and the SOA record's own TTL, and one of the two is probably large. Lower both, and lower them before the change rather than after.
What is a good SOA MINIMUM value?
RFC 2308 says one to three hours works well as a default and that values over a day have been found to be problematic. Lower it further ahead of a planned migration.
What happens when EXPIRE is reached?
The secondary stops answering for the zone entirely. It does not serve stale data; it serves nothing, which is why a short EXPIRE turns a primary outage into a domain outage.
Does the serial number have to be a date?
No. It has to increase, and it is compared using sequence space arithmetic rather than as a plain integer. The YYYYMMDDnn convention is popular because it stays readable and stays ascending.
What happens if I lower the serial number?
Secondaries that already hold a higher serial will not transfer, and they will keep serving the old zone until somebody notices. Recovering usually means bumping well past the old value or resetting the secondaries.
Is the RNAME address real?
It is a real email address written with the at sign as a dot, and in practice it is very often a mailbox nobody monitors. Managed DNS services often fill it in with a generic address of their own. Send a test message before relying on it.
How do I check a domain's SOA record?
dig SOA example.com on Linux or macOS, nslookup -type=soa example.com on Windows. Both read the record straight from DNS. Query each authoritative nameserver directly rather than a resolver when debugging, so you see what is published rather than what is cached.
Do REFRESH and RETRY still matter with NOTIFY?
Less than they used to. NOTIFY pushes changes to secondaries immediately, so REFRESH becomes the fallback for when a NOTIFY is missed rather than the primary mechanism. The values still need to be sane, because the fallback is what runs on the bad day.
Which SOA field affects end users?
MINIMUM, and only MINIMUM. The other four govern how secondary servers behave toward the primary and are invisible to anyone querying the zone.
How do I look up a DNS SOA record?
Run nslookup -type=soa example.com on Windows, or dig soa example.com on Linux and macOS. The DNS SOA record in the answer shows the primary name server, the administrator's mailbox, the serial number and the four timers that secondary servers follow.
Keep readingRelated concepts
Read next · Addressing What Is DHCP? The other half of how a client learns which resolver to ask in the first place. Open this next9 min- DNS · 14 min DNS Not Resolving Where a mismatched serial across nameservers shows up: a change that works for some people and not others.
- Ports · 10 min Port 53, and Why DNS Needs TCP as Well as UDP The port all of this runs over, and the reason zone transfers need TCP open as well as UDP.
- Infrastructure · 12 min What a Load Balancer Does, and the Two Decisions Behind It The reason DNS is not a substitute.