--On Wednesday, January 7, 2004 23:17 +0000 Richard D G Cox <[EMAIL PROTECTED]> wrote:
Nope.
On 7 Jan 2004 23:02 UTC Frank Louwers <[EMAIL PROTECTED]> 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!
| but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?Actually, YES...
Nope!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^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.
pgp00000.pgp
Description: PGP signature
