SOA Lookup
Decode the start of authority record of a zone, see what each timer controls, and check that the authoritative servers carry the same zone version.
Run SOA record
No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.
What the SOA record contains
Every zone has exactly one SOA (start of authority) record at its apex. It identifies the zone's primary server, the contact mailbox, a version number and four timers. Resolvers and secondary servers use it, and the fields are easy to misread because several of them are measured in seconds and one has changed its meaning over time.
If the name you enter is not the apex of a zone, the tool says so and shows the SOA of the zone that contains it. It then asks the authoritative servers for the same record so it can compare their versions.
The fields and what each one controls
- MNAME: the primary name server for the zone. It does not have to appear in the NS list, which is common when a hidden primary or a managed provider is used; the tool notes this and treats it as informational.
- RNAME: the responsible mailbox, written with a dot where the at sign would be. The tool shows the decoded address next to the raw form.
- Serial: the version of the zone. Secondary servers compare it with their own copy to decide whether to transfer the zone. A common convention is YYYYMMDDnn, which the tool recognises and decodes, but the protocol only requires that the number increases.
- Refresh: how often a secondary checks the primary for a new serial.
- Retry: how long a secondary waits before trying again after a failed refresh.
- Expire: how long a secondary continues serving the zone without contact with the primary before it stops answering.
- Minimum: since RFC 2308 this field is the negative-caching TTL, the time resolvers may remember an NXDOMAIN or NODATA answer. The effective value is the smaller of this field and the TTL of the SOA record itself, and the tool shows that effective value.
How to read the result
- Timers within guidance: the tool compares refresh, retry, expire and negative TTL with the ranges recommended in RFC 1912 and RFC 2308 and reports a pass if they fall in range. These are recommendations, not protocol requirements, so deviations are reported as low-severity improvements.
- Serials agree: all answering authoritative servers report the same serial. This is the healthy state for servers of one provider.
- Serials differ: one or more servers are behind. Wait one refresh interval and test again; a persistent gap means a transfer is failing.
- Different providers, different serials: if each serial belongs to a separate DNS operator, the difference is informational, because independent providers keep independent counters.
- Only one usable SOA: agreement cannot be compared, which is reported neutrally.
- SERVFAIL, REFUSED or timeout from a server: the server gave no usable SOA, and nothing is concluded about it.
Why the negative-caching TTL matters
When a name does not exist, the NXDOMAIN answer is cached for the negative TTL. If you query a hostname before creating its record, a resolver may keep saying 'does not exist' for that whole period even after you add the record. A long value therefore stretches out every launch mistake, while a very short one increases query load on your servers. Values of a few minutes to an hour are typical.
This is the reason a freshly created record sometimes appears to be missing from some resolvers but not others.
Common SOA problems
- Serial not incremented after a manual edit: secondaries never fetch the new data and keep serving the old zone.
- Serial that moved backwards: some secondaries then ignore the zone until the serial is raised past the old value.
- Very long negative TTL: one mistaken lookup stays cached for hours or days.
- Very short expire: the zone can stop being served if the primary is unreachable for a short outage.
- Unreachable contact mailbox: the RNAME contact is often outdated and mail to it bounces.
How to change SOA values safely
Most managed DNS providers set the serial and timers for you and may not let you edit them. If you run your own primary, increase the serial on every change, and edit timers conservatively because they affect how fast secondaries catch up and how long they tolerate an outage.
Do not lower the expire value below your longest expected maintenance window. If you reduce the negative TTL, the shorter value reaches resolvers only as their old entries expire.
- Note the current SOA and which servers carry the zone.
- Edit only the field you need, and raise the serial.
- Reload the zone, then re-run this lookup.
- Confirm every authoritative server reports the new serial after one refresh interval.
- To roll back, restore the previous timers but keep the serial higher than any value already published.
What this test does not cover
The tool reads the SOA from up to eight authoritative servers and the system resolver at one moment. It does not trigger or verify zone transfers, cannot see the primary if it is hidden, and does not judge whether the contents of the zone are right.
Frequently asked questions
What is the SOA serial for?
It is the version number of the zone. Secondary servers compare it with their copy to decide whether to fetch an update. It must increase with each change.
Does the serial have to be a date?
No. A date format such as YYYYMMDDnn is a convention. Any increasing number works.
Why does the MNAME not appear in my NS list?
Hidden primaries and managed DNS services commonly use a primary that is not published as a name server. The tool shows this as information.
Why is a new record missing for some people?
Resolvers may be caching an earlier 'does not exist' answer for the negative-caching TTL shown in the SOA.
Is a failed timer comparison an error?
No. The ranges come from RFC 1912 and RFC 2308 and are guidance only. Your provider may use other values deliberately.
Why do two providers show different serials?
Each provider keeps its own counter. The tool treats this as expected and compares serials only among servers of the same provider.
Written by DNS Tools editorial · Last updated 2026-10-09