theweaselking: (Work now)
[personal profile] theweaselking
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.

(no subject)

Date: 2012-02-17 06:26 pm (UTC)
From: [identity profile] pappy-legba.livejournal.com
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.

(no subject)

Date: 2012-02-17 06:41 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
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.

(no subject)

Date: 2012-02-17 10:16 pm (UTC)
From: [identity profile] pappy-legba.livejournal.com
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?

(no subject)

Date: 2012-02-17 10:31 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
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.

(no subject)

Date: 2012-02-18 01:59 am (UTC)
From: [identity profile] kowh.livejournal.com
"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-18 02:05 am (UTC)
From: [identity profile] theweaselking.livejournal.com
Even just have the logs show "received SN X, current SN is Y, slave is up to date" rather than just "slave is up to date".

That would be nice, y'know?

Profile

theweaselking: (Default)theweaselking
Page generated Feb. 6th, 2026 02:39 am