Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
5  
Heads-up: There is no standard format for DNS serial numbers. –  John Gardeniers Jul 7 '10 at 4:01
1  
@John That serial format is recommended by RFC1912 section 2.2. See: faqs.org/rfcs/rfc1912.html –  Justin Scott Jul 8 '10 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. –  John Gardeniers Jul 8 '10 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. –  Justin Scott Jul 8 '10 at 12:39

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
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 '10 at 17:41

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.

share|improve this answer
2  
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. –  John Gardeniers Jul 7 '10 at 4:03

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.

share|improve this answer

Your Answer

 
discard

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.