I have some DNS servers for our organization that was setup by my predecessor. He did not use the standard format for serial numbers, instead he used an odd format starting with 2033. What I want to do is replace his DNS servers with my own but am worried about changing the serial number to a "proper" format by using YYYYMMDDXX because it will be a lower number.

These are our public DNS servers, and I just want to make sure that there will be no issues in doing this. Has anyone had experience in this sort of transition?

  • 6
    Heads-up: There is no standard format for DNS serial numbers. Jul 7, 2010 at 4:01
  • 1
    @John That serial format is recommended by RFC1912 section 2.2. See: faqs.org/rfcs/rfc1912.html Jul 8, 2010 at 0:53
  • @Justin, that is nothing more that a suggestion. It is not a standard. Besides which, an RFC is not a standard anyway. It is a precursor to a recommendation for a standard. Nothing more. Jul 8, 2010 at 4:53
  • @John I didn't say it was a standard, I said it was "recommended". However, nearly every DNS zone I have ever seen uses that format, so you could say it's a de-facto standard. Jul 8, 2010 at 12:39

4 Answers 4


If his number with starting with 2033 is greater then the YYYYMMDDXX standard then you can reset the value.

Here is an article that describes the procedure. Basically you have to exploit the fact that the serial number is a 32 bit integer and will wrap if you use larger values.

  • This is why linking to a solution in stack exchange isn't really providing information. The Link is DEAD!
    – labradort
    May 9, 2018 at 16:16
  • @labradort the still works for me. It got changed to an archive.org link a while ago that is still valid. Here are a couple more links unix.stackexchange.com/questions/36869/… microhowto.info/howto/… I didn't really want to copy-paste the entirety of the pages into an answer. Also, I still think the mention that it is a 32 bit integer is probably enough for most people to current pages via Google.
    – Zoredache
    May 9, 2018 at 20:13
  • "504 Gateway Time-out The server didn't respond in time." - from the original link. Here is some useful information... Bind 9.9 won't do zone transfer via "also-notify" unless the serial number is incremented. Serial number can never advance more than 2147483647 at a time. The equivalent of 99999999 on the odometer is 2^32 - 1 , or 4294967295. Wait for secondary NS to get the new SOA before incrementing so you can get them to all roll forward to the lower value serial number.
    – labradort
    May 10, 2018 at 13:09

I haven't had to do this myself, but I bookmarked a solution (HOWTO Fix SOA RR serial numbers) from the author of the Pro DNS and BIND book in case I make this mistake myself.


You can set the serial numbers to whatever you like. By default the secondary servers won't pull a zone transfer unless the number is higher, but you can command them to force a transfer and reload as long as you have direct access to them. Just set the serial number to what you like, then issue the re-transfer commands to the secondary servers so they will go fetch the new information despite the lower serial number.

  • 3
    And if that doesn't work (at least in that case of BIND) simply delete the zone file(s) from the secondary and have it do a reload, which will cause it to fetch the new copies. Jul 7, 2010 at 4:03

As said, the SERIAL field in an SOA resource record has no so-called "standard format". It isn't even used by all DNS server softwares. (Nowadays, a fair amount of the world doesn't even use zone transfer database replication.) With ISC's BIND, it's just a number with no inherent meaning to its specific value, used to check during zone transfer database replication whether replicas are out of date, and one can choose whatever scheme one likes for setting it, with the proviso, as also stated, that "newer" must mean "a bigger number, modulo 32 bits".

You've already encountered the pitfall here. Whatever scheme one chooses, someone is bound to come along and (lacking information) not understand it, or want to change it, just as you haven't understood and want to change the scheme of the person who came before you. This is the pitfall of not documenting one's system administration choices. So document your choice.

  • Of course there's also the possibility that the predecessor simply didn't think the choice through before making it. I find that one to be the case more commonly than 'there's a reason and it just wasn't documented'.
    – Chris S
    Jul 7, 2010 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .