HOWTO Fix SOA RR serial numbers

This page provides an alternative to ritual suicide if you manage to get the serial number incorrect on an SOA RR.

The serial number field of the SOA RR can take any value but many users, by convention, use a date format most commonly defined to be yyyymmddss where yyyy is the four-digit year number, mm is the two-digit month number, dd is the two-digit day within month number, and ss is a two-digit sequence number within the day. This convention has the merit of being relatively simple to use and also indicates when the zone was last changed - which can occasionally be very handy.

Since this date format is only a convention, BIND and most other DNS software does not validate the format of the serial number; it is thus very easy to introduce errors and get out of sequence values. Zone transfer to zone slave(s) will, in the event of zone file changes, occur only if the serial number of the SOA RR is arithmetically greater that the previous one (as defined by RFC 1982).

To illustrate the fixes possible, it is assumed that today's date is 28 February 2003 (serial number 2003022800). If the erroneous serial number entered is less than today, that is, 2003022700, the fix is trivial: simply correct the serial number and restart (or reload) BIND or reload the zone using rndc. If the number is too high, it depends on how high the number is and how frequently the zone file is changed. Assume the changed serial number was set to 2003022900, which as we all know does not exist, 2003 not being a leap year; however, BIND does not know that and a zone transfer will have taken place, 29 being greater than 28. The simple fix is to increment the date again to 2003030100 and keep using the sequence number until the correct date is reached (tomorrow in this case). This works unless you will require to make more than 99 changes until the new date is reached - in which case perhaps ritual suicide is the best option.

If all the quick solutions are not acceptable, for instance, the serial number is 2008022800, then it's time to get out the calculator or do some serious mental arithmetic. The SOA serial number is an unsigned 32-bit field with a maximum value of ((2**32) -1), which gives a range of 0 to 4294967295 (the value zero may have special significance in certain DNS implementations and should be avoided), but the maximum increment to such a number is ((2**31) - 1) or 2147483647 (incrementing the number by the maximum value would wrap and give the same number). Using the maximum increment, the serial number fix is a two-step process. First, add 2147483647 to the erroneous value, for example, 2008022800 + 2147483647 = 4155506447, restart BIND or reload the zone, and make absolutely sure the zone has transferred to all the slave servers. Second, set the SOA serial number for the zone to the correct value and restart BIND or reload the zone again. The zone will transfer to the slave because the serial number has wrapped through zero and is therefore greater that the previous value of 4155506447!

This method works perfectly unless the sum of the current serial number and 2147483647 exceeds 4294967295 - in this case simply set the serial number to 4294967295 perform the first zone transfer as described above and then set the number to the desired/correct one and restart or reload the zone again. (Thanks to Todd Snyder for pointing out the limitation and the fix). RFC 1982 contains all the gruesome details of serial number comparison algorithms if you are curious about such things.

<grovel> We mistakenly added the following sentences after the overlap fix documented in the previous paragraph "Observant readers will have noted that this method will actually work under all conditions thus saving the computational effort described previously. However, as a service to calculator manufacturers everywhere and the global mental arithmetic alliance, we will leave the first method in place since it, perhaps, describes the fix theory more completely." The truly observant, which, frankly, should have included us, would have spotted the fact that if 4294967295 - current serial number > 2147483647 (the largest increment) then the simplified method will not work. It is not a universal simplification. Many thanks to Anders Andersson for taking the time to point out the problem. We plead an excess of euphoria and have committed to perform all such serial number calculations without using a calculator as an act of atonement - for a strictly limited period!</grovel>

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.