Home › Tools › Network & DNS › Network & DNS Tools
SOA Record Lookup
soa-lookupCheck zone authority configuration and serial data for DNS operations.
Enter a target and run the tool.
Results
| Type | TTL | Value |
|---|
About SOA Lookup
The SOA (Start of Authority) record is the zone-level metadata record that every DNS zone must have exactly one of. It is not an address record or a routing record — it is a control record that defines the authoritative source for a zone and the timing parameters that secondary nameservers use to stay in sync with the primary. The AT USE SOA lookup tool queries live DNS via DNS-over-HTTPS and returns the full SOA record for any domain: the primary nameserver, the responsible-party email, the serial number, and all four timing parameters (refresh, retry, expire, minimum TTL). DNS administrators, DevOps engineers, and system operators use it to confirm zone authority after infrastructure changes, verify that zone edits incremented the serial number, and audit replication parameters that directly affect how quickly DNS changes propagate across a provider's secondary network.
How to look up SOA records
- Enter the apex domain in the input field — for example,
example.com. SOA records exist only at the zone root; querying a subdomain returns the SOA for the parent zone that contains it. - Click Lookup. The tool queries a live public DNS-over-HTTPS resolver and returns the complete SOA record fields.
- Read the result. You will see: the primary NS hostname (the authoritative master), the responsible email (formatted as a hostname with the first
.representing@, sohostmaster.example.commeans[email protected]), the serial number, and four timing values in seconds: refresh, retry, expire, and minimum TTL. - Cross-check the serial number against the value you recorded before a recent zone edit to confirm the change was saved and published. If the serial number did not increment, the zone change did not take effect.
What each SOA field controls
The serial number is a monotonically increasing integer that secondary nameservers use to detect zone changes. When a secondary checks in with the primary and finds a higher serial number, it knows a zone transfer (AXFR/IXFR) is needed to pull the new records. Most DNS providers increment the serial automatically on every zone edit; if you manage BIND or NSD directly, you increment it manually. A common convention is to use the date in YYYYMMDDNN format (for example, 2026060501 for the first edit on June 5, 2026), which makes it easy to see at a glance when the zone was last changed.
The refresh interval (seconds) tells secondary nameservers how often to check the primary for a new serial number. A typical value is 3600 (1 hour) to 86400 (24 hours). Shorter intervals mean secondary servers detect zone changes faster, at the cost of more polling traffic to the primary. Most managed DNS providers set this between 3600 and 21600 seconds.
The retry interval (seconds) controls how long a secondary waits before retrying after a failed check-in with the primary. This value should always be shorter than the refresh interval — typically one-quarter to one-third of the refresh. If a primary is temporarily unreachable, retry governs how quickly secondaries attempt to reconnect.
The expire timer (seconds) is the maximum time a secondary will continue serving the zone without successfully reaching the primary. If the expire time passes with no successful refresh, the secondary stops answering queries for the zone, treating its copy as stale. Production zones typically set this to 604800 seconds (7 days) or higher so that secondary servers continue serving stale data through extended primary outages rather than going dark.
The minimum TTL (also called negative-cache TTL since RFC 2308) controls how long resolvers cache negative responses — NXDOMAIN answers meaning "this name does not exist." If a resolver is told that www.example.com does not exist, it caches that non-existence for this many seconds. A low minimum TTL (300–900 seconds) means newly created records become visible to resolvers quickly after a short cache window expires. A high value (3600 seconds+) means resolvers cache NXDOMAIN longer, which reduces lookup load but slows how quickly new records appear after creation.
Common use cases
- Post-change serial verification — confirm a zone edit was published by checking that the SOA serial number incremented. A serial that did not change means the edit did not save or the DNS provider's publishing pipeline has not run yet.
- Hidden-master DNS validation — verify the SOA's primary NS field names the correct hidden master in a setup where the authoritative primary is not listed in the public NS records.
- Replication timing audit — read refresh, retry, and expire values to confirm that secondary nameservers are configured to replicate changes on the intended schedule — not too slow for high-change zones, not so aggressive that polling traffic becomes excessive.
- Negative-cache TTL diagnosis — check the SOA minimum TTL when newly created records are not appearing for resolvers on time. Resolvers that cached an NXDOMAIN hold it for this duration before re-querying.
How to use this tool
- Enter the domain whose zone authority you want to inspect (for example, example.com).
- Click "Lookup" to query the live SOA record.
- Read the primary nameserver, responsible party, and serial number returned.
- Inspect the refresh, retry, expire, and minimum-TTL values to assess zone health.
Frequently asked questions
What is the serial number in an SOA record and what should it look like?
The serial number is a 32-bit unsigned integer that secondary nameservers compare to detect zone changes. When a secondary's copy has a lower serial than the primary, it triggers a zone transfer to pull the updated records. Common conventions are a plain integer incremented on each edit, or a date-based format like YYYYMMDDNN (for example 2026060501 for the first edit on 2026-06-05). Most managed DNS providers increment the serial automatically.
Why does the SOA show a different primary nameserver than my NS records?
This is intentional in a hidden-master setup. The SOA mname field names the primary nameserver that zone data originates from, which may be a server not listed in the public NS records. NS records list only the servers that answer public queries. A mismatch between the two is a valid and common architecture choice, not a misconfiguration.
What happens when the SOA expire timer runs out?
If a secondary nameserver cannot reach the primary for longer than the expire duration, it stops answering queries for the zone. From the outside, the domain stops resolving on that secondary. Setting expire to at least 7 days (604800 seconds) ensures secondary servers continue serving during extended primary outages rather than going silent. Most providers default to values between 1 and 2 weeks.
How does the minimum TTL affect how quickly new records appear?
The SOA minimum TTL controls how long resolvers cache negative responses (NXDOMAIN — "this name does not exist"). If a resolver cached an NXDOMAIN for your hostname before you created the record, it will not retry until that TTL expires, regardless of how short the new record's own TTL is. A minimum TTL of 300 seconds means the NXDOMAIN cache clears within 5 minutes; 3600 seconds means up to 1 hour.
Can I edit SOA record values, or does my DNS provider control them?
It depends on the provider. Managed DNS services (Cloudflare, Route 53, Google Cloud DNS) automatically manage the serial, refresh, retry, and expire values and may not expose them for manual editing — they tune the parameters for their infrastructure. Self-managed BIND or NSD deployments give full control over all SOA fields. Even where providers expose the minimum TTL setting, the serial is almost always auto-managed.
Does the SOA record affect website or email performance?
Not directly for end users. SOA parameters affect DNS replication speed between the primary and secondary nameservers. For most domains on managed DNS providers, these values are already tuned and have no practical effect on day-to-day resolution speed. They matter most when troubleshooting zone replication issues, NXDOMAIN caching problems, or confirming that zone changes propagated to secondary servers within an expected timeframe.