VeriSign Naming and Directory Services will change the serial number
format and "minimum" value in the .com and .net zones' SOA records on
or shortly after 9 February 2004.
The current serial number format is YYYYMMDDNN. (The zones are
generated twice per day, so NN is usually either 00 or 01.) The new
format will be the UTC time at the moment of zone generation encoded
as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1
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.
This Perl invocation converts a new-format serial number into a
meaningful date:
$ perl -e 'print scalar localtime 1076370400'
At the same time, we will also change the "minimum" value in the .com
and .net SOA records from its current value of 86400 seconds (one day)
to 900 seconds (15 minutes). This change brings this value in line
with the widely implemented negative caching semantics defined in
Section 4 of RFC 2308.
There should be no end-user impact resulting from these changes
(though it's conceivable that some people have processes that rely on
the semantics of the .com/.net serial number.) But because these
zones are widely used and closely watched, we want to let the Internet
community know about the changes in advance.
Matt
stuid question, but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?
Kind Regards,
Frank Louwers
Frank Louwers wrote:
stuid question, but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?
Are you suggesting Yet Another Carefully Thought Out Change?
Well, it _is_ the first one this year.
> 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)?
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!
I think what Frank is asking is a valid question.
The way BIND/etc determine when a new zone file has been issued is by
seeing if it has a higher SN than the currently caches zone.
Frank's question is that when view simply as 10 digit integers (which is
how BIND uses them) 2004010801 is a larger integer than 1076370400.
This might cause problems with cached zones and other such staleness, so
it does seem a valid concern.
-Scott
Don't they use YYYYMMDDNN now? So today's version whould be 2004010801.
AFAIK, 1076370400 is actually "less" then 2004010801...
I know there are ways to "trick" nameservers in believing less is more,
but that requires at least 2 changes, and I don't know if that is
actually RFC-compliant behaviour...
Kind Regards,
Frank Louwers
Um, isn't the serial number in a zone file read in by BIND as a standard
integer? If so, then 2004010101 (date format serial) would be > 1076370400
(UTC serial number) when compared wouldn't it as they are both 10 digit
integers.....?
/Alex K.
Don't they use YYYYMMDDNN now? So today's version whould be 2004010801.
AFAIK, 1076370400 is actually "less" then 2004010801...
I know there are ways to "trick" nameservers in believing less is more,
but that requires at least 2 changes, and I don't know if that is
actually RFC-compliant behaviour...
maybe someone would like to read rfc 2182 section 7
randy
Remember this is Verisign we're talking about, RFC's need not apply. More
notably RFC1912 which recommends the YYYYMMDDnn format.
If CTO at Verisign's head splits open and a UFO should fly out, I want you
and everyone on this list to have expected it.
Considering that using the YYYYMMDDnn format would still permit them 100
updates per day (every 15 minutes or so) you'd think they'd stay with the
RFC.
nah....
*grumble*
VeriSign Naming and Directory Services will change the serial number
format and "minimum" value in the .com and .net zones' SOA records on
or shortly after 9 February 2004.
[snip]
But because these
zones are widely used and closely watched, we want to let the Internet
community know about the changes in advance.
Matt, was it not possible for Verisign to give more than 30 hours notice of these changes? This is an Internet-wide change that will very likely break some systems somewhere. Surely more notice would have been reasonable.
The notice actually given is so short as to be almost worthless. It might have raised Verisign's moral stock around here if more notice had been given, or even some consultation issued. As it is, Verisign seem to have moved in a way that, yet again, is likely to convince the community of Verisign's apparent arrogance and contempt towards the rest of us. Sad.
Alexander Kiwerski 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)?
>
>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!
Um, isn't the serial number in a zone file read in by BIND as a standard
integer? If so, then 2004010101 (date format serial) would be > 1076370400
(UTC serial number) when compared wouldn't it as they are both 10 digit
integers.....?
And from the stupid question file, is 1912 a standard? (RFC Editor
says it is "Informational".
"Laurence F. Sheldon, Jr." wrote:
And from the stupid question file, is 1912 a standard? (RFC Editor
says it is "Informational".
And it is amusing to read what it says about wild cards too.
Go read RFC 1982. They can do it that way without any real trouble as
long as all of the secondary (B-M) servers are tweaked. Check out section
7 in particular.
---> Phil
I know, but:
- they didn't mention it
- are all dnsserver rfc compliant?
Vriendelijke groeten,
Frank Louwers
Go read RFC 1982. They can do it that way without any real trouble as
long as all of the secondary (B-M) servers are tweaked. Check out section
7 in particular.
I know, but:
- they didn't mention it
the number of things they did not mention is O(aleph null), perhaps
you are supposed to know some of them.
- are all dnsserver rfc compliant?
maybe you should take care of yours and let verisign take care of
theirs.
randy, who is enough of a klutz that he does not have to constantly
search for others to blame
I didn't notice anybody saying "thank you for doing the right thing by announcing the change" amongst the flurry of jerking knees. So, thank you for doing the right thing. Good luck with the maintenance.
Joe
>VeriSign Naming and Directory Services will change the serial number
>format and "minimum" value in the .com and .net zones' SOA records on
>or shortly after 9 February 2004.
^^^^^^^^
[snip]
Matt, was it not possible for Verisign to give more than 30 hours notice of
^^^^^^^^^
these changes? This is an Internet-wide change that will very likely break
some systems somewhere. Surely more notice would have been reasonable.
I'd say more than 30 days is enough for what amounts to a trivial change
that really only affects their slave name servers.
Jim
>VeriSign Naming and Directory Services will change the serial number
>format and "minimum" value in the .com and .net zones' SOA records on
>or shortly after 9 February 2004.
Matt, was it not possible for Verisign to give more than 30 hours notice
of
these changes? This is an Internet-wide change that will very likely break
some systems somewhere. Surely more notice would have been reasonable.
If you reread the original mail, they gave us 32 days of notice. The change
will not be happening until February 9.
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam@reachone.com