Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have recently 'inherited' a tiny bind9 DNS server (64MB RAM running bind9+ssh only) where the zones were crafted using a GUI application then scp'd into the server as root. I didn't really mind that part, but turns out the GUI application made inconsistent serial numbers every edit, resulting in serials such as 1245486432 instead of the 'common' (?) YYYYMMDDSS.

Is there a 'safe' way to increase/decrease the serial number without causing any sort of inconsistencies between DNS servers and caches?

share|improve this question
Watch out! This is a tiny BIND DNS, not a tinyDNS :). – chmeee Jul 6 '09 at 8:49
up vote 6 down vote accepted

The serial is used by slaves to determine whether the zonefile they have is the same revision that the master holds. When the master's serial is incremented, they know that they have to AXFR a new copy. The only harm will come from decrementing because the slaves will think they have a later revision than the master is holding.

There are two solutions to this. The simplest is to decrement your master, remove copies from the slaves and then have them reload. However this won't work if you're not in full control of the slaves. In which case a solution is provided in the Reference Manual.

Add 2147483647 (2^31-1) to the number, reload the zone and make sure all slaves have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.

Just of note, it's best to use the last two digits of the serial to store a revision, rather than seconds. ie YYYYMMDDRR. This allows to you make multiple updates within the same day.

share|improve this answer
'SS' meant 'sub serial', but I guess RR explains it better. – LiraNuna Jul 6 '09 at 17:52

I've used some "magic" DNS serial number arithmetic to move back to the more regular YYYYMMDDSS scheme, I did however have the safety net of beeing able to go and manually force slaves into submission and flush caches if need be.

RFC 1982 defines a maximum increment of 2147483647 (2^31 - 1) and the DNS & Bind Cookbook has a recipe for resetting the serial in this way. Basically add max increment to your current serial, reload your zone, wait for slaves to pick up the change, change serial to something you want and reload your zone again.

share|improve this answer
However, re-reading the question your current serial 1245486432 is less than 2009060600 and the difference is less than the maximum defined increment, so you should be able to just set your serial to YYYYMMDDSS, reload your zone and be on your way. – Kjetil Joergensen Jul 6 '09 at 9:15

Incrementing is safe, as x > y is the test, however to decrement you often need control of all slaves to force them to load (what they think of as) an old zone.

It depends on the slaves, but for Bind the easiest way is to stop, rm the slave file and start. You can force a reload via RNDC if you want to learn that.

share|improve this answer
This is incorrect. – womble Jul 6 '09 at 9:10
womble - any backup to that, all the other posters seem to agree with me (albeit their posts are better written) – LapTop006 Jul 6 '09 at 12:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.