The serial that never incremented
Why the number matters more than the data
Every SOA record carries a serial — a 32-bit counter whose only job is to tell secondary nameservers whether the zone has changed. Secondaries poll the primary on their refresh interval, compare the incoming serial with the one they hold, and pull a new copy only if the number has gone up. The content of the zone is irrelevant to that comparison. The serial is the signal.
This makes the failure mode precise: edit the zone, push the data, forget to increment the serial, and every secondary keeps serving the old version indefinitely. No error is logged anywhere. The primary answers correctly; the secondaries answer confidently; they simply disagree, and because zone transfer is not attempted, nothing in the infrastructure surfaces the gap. Monitoring that checks whether secondaries are reachable will report green.
The SOA serial ↗ comparison follows a rule defined in RFC 1034 and refined for sequence-number arithmetic in RFC 1982: a serial is considered newer if, in 2³² serial-number arithmetic, it is greater than the one the secondary holds. This means a serial that wraps past 2³² back toward zero is handled correctly — but a serial that stays the same is not newer by any arithmetic. The secondary waits for the next refresh interval and checks again. Finds the same number. Waits again.
The standard timestamp convention — YYYYMMDDNN, where NN is a same-day revision counter — exists specifically to make forgetting harder. A date-stamped serial makes a forgotten bump easier to spot, because a serial carrying last year's date is obviously stale. But conventions are not enforcement. BIND, Knot ↗, NSD and PowerDNS all accept whatever serial the zone file contains and update it only if explicitly told to. Some operators automate the increment; many do not.
The fix after the fact requires bumping the serial past whatever the secondaries already hold, reloading the primary, and waiting for the refresh interval to expire — or manually triggering NOTIFY, which causes secondaries to check immediately rather than on schedule. NOTIFY was standardised in RFC 1996 ↗ precisely to collapse that wait, but it still depends on the serial being higher. Without the increment, NOTIFY is also silent.
The lesson is narrow: the serial is not metadata. It is the mechanism. Every automation that touches a zone file and skips the serial update is building in a silent failure path.
Secondaries poll the primary on their refresh interval, compare the incoming serial with the one they hold, and pull a new copy only if the number has gone up.
Every automation that touches a zone file and skips the serial update is building in a silent failure path.