DNS - Year 2043 apocalypse ;-)

[Barry Margolin]

In article <001601bf5867$2c9807e0$857c06d1 at aranea.cybergood.net>,
Alex Miller <bind-users at bannerclub.com> wrote:
>Ok, kidding aside I've come up with an interesting
>problem with serial numbers.
>
>Let's say I decide to use the convention
>YYYYMMDDHHSS for serial dates. So a dns change made
>right now (as I'm writing) would be 200001061133
>(2000, January 6, 11:33 EST), because my primary
>dns server is on the East Coast.
>I make lot's of typos so needing to distinguish
>between one update and another a few minutes later
>is important to me.
>
>Well, that doesn't work too well, because the number
>is too large "as a number" and when you query the zone
>record it looks nothing like the YYYYMMDDHHSS.
>Of course, unlike the tantalyzing subject of this
>message such a transformation is hardly apocalyptic,
>so beat me.
>
>Anyway, instead I adopt the convention:
>YYMMDDHHSS

A common convention is YYYYMMDDnn, where nn is just a counter that
increases by 1 every time you rebuild the zone that day.  If you rebuild
more than 100 times, you can overflow into the next day's serial numbers.

We use a script to build our zone files.  We use the above format, but nn
is the time of day as a percentage, e.g. noon would be 50.  That way the
script that builds the new files doesn't have to read the old files to get
the previous serial number and increment it.  1/100'th of a day is about 15
minutes; since our script normally takes longer than that to run, there's
not much danger of it generating the same serial numbers on successive
runs.

This scheme won't overflow the serial number for more than 2,000 years.  I
think the computers of that millenium will be smart enough to devise their
own solution.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.