Upcoming change to SOA values in .com and .net zones

Thu Jan 8 04:06:24 UTC 2004

--On Wednesday, January 7, 2004 23:17 +0000 Richard D G Cox 
<Richard at mandarin.com> wrote:

>
> On 7 Jan 2004 23:02 UTC Frank Louwers <frank at openminds.be> wrote:
>| > generated twice per day, so NN is usually either 00 or 01.)
>| > January 1970.)  For example, a zone published on 9 February 2004 might
>| > have serial number "1076370400".  The .com and .net zones will still
>| > be generated twice per day, but this serial number format change is in
>| > preparation for potentially more frequent updates to these zones.
>
>| stuid question
>
> Yup!
>
Nope.

>| but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?
>
> Nope!
>
Actually, YES...

>>> The new format will be the UTC time at the moment of zone generation
>>> encoded as the number of seconds since the UNIX epoch.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ... and not as YYYYMMDDHHMMSS or any contracted version thereof!

Right, but, the _OLD_ format is.  Therefore, the old zone file prior to
the conversion will be SN 2004020800 through 2004020901.  After the change,
the SN will be in the range 1076284800 through 1076371200 inclusive.
This complete range is less than 2004020800, so, the serial number will,
indeed, be going backwards at the time of the change.  This should only
matter to things doing automated zone transfers and a forced manual zone
transfer should solve the problem.  Presumably, the responsible TLD 
operators
are being coordinated with to take the necessary steps.  Anyone else doing
zone transfers of COM and NET has now been warned and should take 
appropriate
action.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040107/4532d93c/attachment.sig>