Apply the rule to DNS SOA serials

Serial arithmetic helps compare copies; it neither guarantees synchronization nor authenticates a server.

• DNS SOA uses SERIAL_BITS=32, labels 0 through 4294967295, and maximum defined increment 2147483647. A serial of 4294967295 incremented by one becomes zero. The four-byte fields in this drawing are only SERIAL, not a complete SOA record or DNS packet (§7; RFC 1035 §3.3.13).
• A secondary holding 4294967295 can recognize primary serial zero as newer by one. The figure is a comparison after observing an SOA, not an invented request/response sequence or an automatic transfer guarantee. RFC 1982 defines arithmetic; the DNS’s actual zone maintenance and transfer rules live in the DNS specifications (§§1,7–8).
• Care should be taken not to advance by more than 2147483647, in one or more steps, within SOA.expire. Every increment starts a new sequence and continues all earlier sequences begun within that period. A single fixed-origin counter or per-step check misses this caution (§7). The illustration chooses expire=10 time units and three increments of 1000000000 at times 0,4,8; their sum 3000000000 exceeds the limit, so an old secondary at zero can compare the primary’s 3000000000 as older.
• Special circumstances can require setting aside the increment caution, such as deliberately lowering a serial. Then take special care to verify ALL servers followed the primary’s changes at EACH step; no universal automatic reset recipe follows. Zero has no arithmetic special meaning, but the RFC warns that some DNS implementations incorrectly treated it specially (§7).
• An offline helper can flag risky increment windows but cannot establish that real servers synchronized. Its chosen half-open time-window convention is a local audit policy, not a DNS protocol timer rule. Section 9 does not consider security and claims neither to add to nor lessen existing DNS security issues. A newer serial does not authenticate its sender; this guide adds no DNS security mechanism (§9).