Yes, John, "201202043" *is* smaller than "2011121801", and that *is* why the slave server is insisting it's up to date despite having an older copy of the zone file.
A straight integer comparison of date strings? Sounds like someone was assuming the presence of overloading on a basic comparison op that is, in fact, not overloaded in the way they want.
Zone file serial numbers are arbitrary, set by the creator. A slave compares the number on the master's zone file to its own, to see if there are any changes to copy. If the number on the master is larger than the slave, the slave does a zone transfer and copies the changes. If not, it doesn't. If you update the master zone file but fail to update the serial number, the zone doesn't transfer. If you put in a LOWER serial number, for example by failing to notice that "3" and "03" are different, the zone doesn't transfer.
Convention is to set the zone serial number to the current date, and then an extra digit or two in case you want to make changes more than once on the same day. This is so you have a very quick way of seeing when the last change was made, and also so your new serial number will always be higher than the previous ones. But the number doesn't MEAN anything, and there might be a reason why you wanted it to not make a zone transfer to the slave quite yet, so it doesn't complain if you left the number the same or made it smaller when you make the edit.
Ah. I've seen similar conventions in use where more elaborate versioning systems are unneeded/unwanted/unfunded. Was this you forgetting the leading zeroes, or catching someone else's mistake?
My own mistake. The change was a tiny change to a single record that didn't actually get *noticed* for two weeks. Once it was noticed, the question started with "Hey, the slave doesn't know the answer" and went quickly into "and the master does, and hmm they're not transferring. Why?"
And two people (one of them was me!) knew to check the serial number and looked RIGHT AT IT and said "no, that looks right!" before looking for something deeper.
"Check the serial" is so frequently the solution to any DNS issue, I can't understand why it hasn't been automated long ago*. It's not like it's hard to implement, or backwards incompatible.
* Yes, some do, but if BIND doesn't do it by default it doesn't count.
(no subject)
Date: 2012-02-17 06:26 pm (UTC)(no subject)
Date: 2012-02-17 06:41 pm (UTC)Convention is to set the zone serial number to the current date, and then an extra digit or two in case you want to make changes more than once on the same day. This is so you have a very quick way of seeing when the last change was made, and also so your new serial number will always be higher than the previous ones. But the number doesn't MEAN anything, and there might be a reason why you wanted it to not make a zone transfer to the slave quite yet, so it doesn't complain if you left the number the same or made it smaller when you make the edit.
(no subject)
Date: 2012-02-17 10:16 pm (UTC)(no subject)
Date: 2012-02-17 10:31 pm (UTC)And two people (one of them was me!) knew to check the serial number and looked RIGHT AT IT and said "no, that looks right!" before looking for something deeper.
(no subject)
Date: 2012-02-18 01:59 am (UTC)* Yes, some do, but if BIND doesn't do it by default it doesn't count.
(no subject)
Date: 2012-02-18 02:05 am (UTC)That would be nice, y'know?