Serial number format

The serial is the zone's version number, and it exists for one purpose: a secondary asks the primary for the SOA, compares serials, and pulls a new copy only if the primary's is higher. Everything about it follows from that — including the fact that where zone transfers are not how a zone is replicated, nothing reads it at all.

That is why a serial of 0 or 1 that never moves is graded as normal rather than as a stale zone. Route 53, Azure DNS and several other managed services replicate through their own control plane and leave the serial where it started. If you do run your own secondaries, the same value is a serious problem, because they will never see an update.

Two conventions are common in zones that use it: YYYYMMDDnn, which is readable at a glance, and a plain counter or Unix timestamp, which is not but is equally valid. This check decodes a ten-digit value as a date where it plausibly is one, and says so where it is not — ten digits is also exactly the width of a Unix timestamp, and treating every one of those as a malformed date would flag a large number of correctly configured zones.

The one value that is genuinely wrong is a serial dated in the future, because it leaves no room to increment today without going backwards. Going backwards is the failure that matters: secondaries compare serials using the arithmetic in RFC 1982, conclude the new zone is older than the copy they hold, and correctly refuse the transfer. Replication stops, and nothing logs an error on the primary.

Pick one scheme and keep it. Mixing a date-based serial with a counter is how a zone ends up going backwards, because the counter is always the smaller number.

If the serial has already gone backwards, do not force the transfer. Publish a serial above the highest value still in circulation and let replication resume normally. For a serial that has wrapped badly, the RFC 1982 route is to increment by 2147483647, let every secondary catch up, then set the value you actually want.

If the serial does not change when you edit the zone, look at whatever generates it. A zone rebuilt from a template that hard-codes the serial publishes edits no secondary ever pulls, and the symptom shows up on the secondaries rather than where the fault is.