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?
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.
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.
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.
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.