DNS
SOA record checker
Read a zone’s SOA record as seven plain-English timers, and catch a serial or a refresh that will cause real trouble.
Free, no accountLive check
Result
The verdict appears here once you press Check the SOA record.
What this is
This soa record checker fetches a domain’s SOA record and turns its seven raw fields into timers you can actually read, each shown in seconds and in the plain words a panel would use instead.
An SOA record is the one record every zone apex must have, and RFC 1035 §3.3.13 defines its seven fields: the primary nameserver, a mailbox for whoever is responsible, a serial number, and four timers - refresh, retry, expire and minimum - that govern how secondary nameservers keep their copy of the zone in step with the primary.
The serial is just a number a secondary compares against its own cached copy: a higher serial means the zone has changed and is worth pulling again. Nothing requires it to look like a date - RFC 1982’s serial number arithmetic treats any larger number as valid - but RFC 1912 §2.2 recommends the YYYYMMDDnn shape because a person reading it can tell when the zone last changed at a glance.
For what each of the four timers here controls in plain words, and how NS and SOA fit alongside the other records a domain needs, see our blog guide "The DNS records a domain needs, and what each one actually does."
How to read the result
The table lists every timer in seconds, which is what actually governs the zone, next to the plain-words version, so "3600" and "one hour" sit side by side instead of asking you to do the arithmetic.
A warning here is almost always about a timer set too loosely for how the zone is actually run - a refresh so long a secondary barely checks in, or an expire so short a brief outage at the primary takes the whole zone offline. None of them mean the zone is broken right now.
Common mistakes
What goes wrong most often, and how to tell.
- Reading a non-date-stamped serial as an errorA serial that is not YYYYMMDDnn still works exactly as intended as long as it keeps increasing; RFC 1982 defines serial comparison that way regardless of what the number looks like. It only means a reader cannot glance at it and tell when the zone last changed.
- Setting retry longer than refreshRetry is meant to be the shorter wait a secondary uses after a failed attempt, tried again sooner than its normal refresh interval. A retry value longer than refresh defeats that purpose and leaves a secondary stuck waiting even after things recover.
- Confusing minimum with an ordinary record’s TTLSince RFC 2308 §4 redefined it, the SOA minimum field governs how long a "no such name" answer is cached, not how long ordinary records in the zone live. A large minimum makes a typo stay unreachable long after the typo is fixed, which has nothing to do with any record’s own TTL.
Questions
What people ask about this tool.
- No. RFC 1982’s serial number arithmetic only requires that a new serial compare as larger than the one before it; RFC 1912 §2.2 recommends the YYYYMMDDnn shape purely so a person can read a date off it, not because any protocol depends on that shape.
- It sets how long a secondary nameserver keeps answering with its last known copy of the zone if it cannot reach the primary at all. Once expire runs out with no successful refresh, the secondary stops answering for that zone entirely rather than risk serving something too stale.
- The minimum field is the negative caching TTL RFC 2308 §4 defines: it governs how long resolvers remember that a name does not exist, so it only shows up when someone does get a name wrong, and a long value then makes that mistake look unfixed for longer than it actually is.
- Either the name is not a zone apex on its own - a subdomain living inside a larger zone has no SOA of its own, and that is normal - or the zone behind an apex that should have one is broken and needs attention from whoever manages its DNS.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 1035: Domain Names - Implementation and Specification” read 13 October 2026
- IETF, “RFC 1912: Common DNS Operational and Configuration Errors” read 13 October 2026
- IETF, “RFC 1982: Serial Number Arithmetic” read 13 October 2026
- IETF, “RFC 2308: Negative Caching of DNS Queries” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.