DNS - Year 2043 apocalypse ;-)

Joseph S D Yao jsdy at cospo.osis.gov
Thu Jan 6 17:44:42 UTC 2000


On Thu, Jan 06, 2000 at 11:57:54AM -0500, Alex Miller 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
> 
> The datetime/serial number would be
> 0001061146 
> 
> This works ok, when I do a dig on a domain
> with a datetime/serial in that format it looks
> like I would expect, pretty much.
> It would look like 1061146. Not as nice as I'd
> like but close enough.
> 
> On Jan, 1 2010, the stripping of the leading
> zeros will end, oh joyful day.
> That datetime/serial will read
> 1001010000 at the stroke of midnight EST
> or whereever the primary server happens
> to be.
> 
> But that happy time will be shortlived.
> The last date which will "look good" will
> be 4212312359 (2042, December 31, 23:59)
> 
> One minute later the leading 42 will become
> a leading 43 which will topple the number
> over the max size of the serial numbers.
> 4301010000 will yield 6042704
> 
> And then the tidal wave in upstate NY due
> to global warming ... ;-)
> 
> Alex Miller

That's why many of us follow the recommendation for:
	YYYYMMDDNN
I do NOT plan to change my zones every second, or more than 99 times in
a day.

Given that 2^32 = 4294967296, we are good for another 2.294 millennia.
By which time I sincerely hope that we all will have agreed to extend
time_t to longer than 32 signed bits, and the serial number to longer
than 32 unsigned bits.

-- 
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.



More information about the bind-users mailing list