SOA serial mismatch between nameservers
Every zone has an SOA record containing a serial number. Secondary nameservers compare their serial with the primary’s, and fetch a fresh copy of the zone only when the primary’s is higher. If your nameservers report different serials, some of them are serving out-of-date data (RFC 1912).
Why it matters
Visitors get different answers depending on which nameserver their resolver asks. A change you made may seem to work for you and not for others, and the inconsistency can last until you notice and intervene.
Common causes
- Zone transfers are failing because a firewall blocks TCP port 53, or the primary does not allow the secondary to transfer.
- NOTIFY messages from the primary are not getting through, so secondaries wait for their next scheduled refresh.
- The primary was edited without increasing the serial, so secondaries think nothing changed.
- The serial was lowered, for example after restoring a backup, so secondaries ignore the “older” zone.
- A secondary is down or has lost the zone entirely.
How to fix it
- Run DNSLint and note which servers report a different serial.
- Make sure each change you make to the zone increases the serial. The common convention is
YYYYMMDDnn: the date plus a two-digit counter for changes that day. - Check the primary allows transfers to the lagging server, and that TCP port 53 is open between them.
- If a serial was lowered, raise it above the highest value any secondary has seen.
- Ask the lagging server to refresh, or wait for the SOA refresh interval, then run the check again.
If you use a managed DNS provider, they handle transfers for you. A persistent mismatch is then worth reporting to their support.