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.

On 7 Jan 2004 23:02 UTC Frank Louwers <frank@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! | 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! -- Richard

...

| but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?

yup.

... 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.

yup.

This might cause problems with cached zones and other such staleness, so it does seem a valid concern.

it'll be fine. this protocol detail only matters between master and slave servers having an AXFR or IXFR relationship. since verisign runs all of the authority servers for COM and NET, they can manage the serial number "rollback" as a strictly internal matter. it's only if the master is run by one party and the slave(s) are run by other parties that serial number arithmetic comes into play. since these servers are all run by one party (that is, verisign itself), they can work privately to ensure that "less" does not mean "backward" in this transition. in the past, when COM and NET were served by the root name servers, verisign would have had to coordinate a change like this according to the rules of DNS, implementation-specific rules of BIND and whatever else was running then, and the group's coordination and monitoring rules. those days are gone. verisign isn't doing anything wrong in this change, and it's probably going to work out just fine. -- Paul Vixie

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

On Wed, 7 Jan 2004, Robert Blayzor wrote:

On 1/7/04 6:31 PM, "Frank Louwers" <frank@openminds.be> wrote:

...

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...

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*

On Wed, Jan 07, 2004 at 04:08:01PM -0800, Philip J. Nesser II wrote:

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 - are all dnsserver rfc compliant? Vriendelijke groeten, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium

In message <20040107231727.714B.RICHARD@mandarin.com>, Richard D G Cox writes:

On 7 Jan 2004 23:02 UTC Frank Louwers <frank@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!

| but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)?

Nope!

Now I'm very confused -- bc says that it is... (Well, I used 2004010700, which is what I get for the current SOA.) --Steve Bellovin, http://www.research.att.com/~smb

Alexander Kiwerski wrote:

On 7 Jan 2004 @ 15:25 PST Richard DG Cox wrote:

...

|On 7 Jan 2004 23:02 UTC Frank Louwers <frank@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!

| 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".

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

On 7 Jan 2004 23:02 UTC Frank Louwers <frank@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.

...

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

At 00:01 08/01/2004, Ian Mason wrote:

At Wed, 7 Jan 2004 17:46:23 -0500, Matt Larson wrote:

...

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.

Whoops, here I sit with egg on my face. My excuse for misreading the date was it was late in the day here after a busy evening. I unreservedly apologize for my haste in condemning Verisign and withdraw my remarks. I shall now go and penitentially stand in the very heavy rain and wind that England is enjoying today. Ian

...

I shall now go and penitentially stand in the very heavy rain and wind that England is enjoying today. I'll do the same (same weather in .be today :(() for irritating randy :)

hey, we got six inches (about 15cm) of snow on the island, and snow is a once every three year thing for us. randy

On Thu, Jan 08, 2004 at 11:24:33AM +0100, Stephane Bortzmeyer wrote:

...

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.

And should we thank Verisign for doing for a very minor change what they did not do for a much more crucial change, their wildcards?

Yes we should, and furthermore we should pull out heads OUT of our asses and stop being so holier-than-thou about it. Verisign is learning their lesson, and it might take a while yet, but yes you should be very grateful they gave you some notice. This community needs to work together, not apart. Verisign didn't do right last time, but they did this time. Drop the grudge, and give them a break. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet: irc.mindspring.com (Earthlink user access only)

.....

...

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.

And should we thank Verisign for doing for a very minor change what they did not do for a much more crucial change, their wildcards?

An optimist might say: Maybe they are learning.... -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-)

The only impact is to our mailboxes wrt messages from people who do not fully grok the (non)issue.

--On 08 January 2004 11:54 +0100 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

For very minor changes, they tell the 200 technical zealots

Noted, but the large number of rabid posts on nanog about said minor change doesn't exactly make it *harder* for them to propagate the "200 zealots" theory!

--On Wednesday, January 7, 2004 5:43 PM -0800 "Martin J. Levy" <mahtin@mahtin.com> wrote:

...

There should be no end-user impact resulting from these changes ...

I believe there have been 26 (opps, now 27) responses to this announcement in the last 2 hours 45 minutes, that's about one response every 6 minutes.

Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-)

Martin

I never expected to find myself defending Verisign, but, in this case, I have to point out the following: 1. Most of the flap has been people demonstrating that they don't understand the effect of the change. On a technical level, all that _SHOULD_ care about the zone serial number is the slave servers that are authoritative for the zone. 2. Some of the flap has been from people that can't read and seemed to think that the change was for Jan 9 instead of Feb. 9. 3. Some of the flap was from people who thought that the serial number going backwards was a serious operational issue. 4. Some of the response to 3 was from people who didn't realize that the serial number really was going to go backwards. 5. Eventually, the fact that this didn't matter was pointed out by some. I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. However, I don't see any meaningful reason for them not to do this either. Having said that, I think that, for once, they actually did provide reasonable notification of the change, and, were extra helpful showing the simple perl conversion from new-format serial number to timestamp. I think we should be praising them for this, accepting that it is a minor change, and appreciating the actual advance notice. I think we should make it clear that we as a community are not a band of engineers opposed to changes for the sake of opposing change and keep it clear that there were real operational impact reasons to oppose the wildcard records. This change isn't worth opposing, and, at least they gave us reasonable notice on it. We should move on. Just my $0.02, but, I think we should declare this horse dead. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

...

encoded date). It doesn't provide the functionality they are striving for.

actually, I think it does.

...

However, I don't see any meaningful reason for them not to do this either.

I am a (currently unemployed) mouse. I worry when the cat announces changes that the cat says are of no interest to mice.

I worry especially when I can not clearly see a benifit to either cat or mice.

Look again. They may wish to make more than 99 updates a day to the zone(s) and the yyyymmddxx format is kind of restrictive in that regard. --bill

On Fri, 09 Jan 2004, Robert E. Seastrom wrote:

I'm just hoping that the choice of a time_t as serial is not a harbinger of djbdns in the gtld servers...

No. All 13 .com/.net name servers now run ATLAS (and have for just over a year), our own from-scratch DNS server implementation. Nothing else met our requirements (such as performance, scaling, and price per query). The size of the .com zone is now well into 64-bit space and we handle over 10 billion queries across all the servers in a typical day, so there are some interesting challenges. ATLAS is also tied in directly to the .com/.net registry database to allow the more frequent updates alluded to in my original posting. The architecture is pretty cool, but unfortunately we don't (yet) have any publicly available white papers on it. Matt

Joe Abley wrote:

On 8 Jan 2004, at 11:35, Owen DeLong wrote:

...

I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for.

If they are going to do zone updates every 15 minutes, then that's 96 serial bumps per day. They could fit that in the the two-digit nn in YYYYMMDDnn, but it wouldn't leave an awful lot of room for any additional ad-hoc serial bumps that might be necessary to address operational problems.

YYYYMMDDnnn exceeds 32 bits for contemporary values of YYYY, so that's not a viable alternative. YYMMDDnnn would work, but has Y2K-ignorant connotations (not that that's particular relevant, post Y2K). Using a second-counter from the unix epoch seems like a perfectly reasonable solution to me.

If it doesn't matter to anybody, and nobody cares, and the value (current and proposed) is irrelevant, why not just add "1" to the current value and stop worrying about it?

Subject: Re: Upcoming change to SOA values in .com and .net zones Date: Thu, Jan 08, 2004 at 08:35:54AM -0800 Quoting Owen DeLong (owen@delong.com):

I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for.

Oh, but I can see why. The primary master server's implementor might choose to autoincrement the SOA SERIAL if any of the following events occurs: (1) Each update operation. (2) A name, RR or RRset in the zone has changed and has subsequently been visible to a DNS client since the unincremented SOA was visible to a DNS client, and the SOA is about to become visible to a DNS client. (3) A configurable period of time has elapsed since the last update operation. This period shall be less than or equal to one third of the zone refresh time, and the default shall be the lesser of that maximum and 300 seconds. (4) A configurable number of updates has been applied since the last SOA change. The default value for this configuration parameter shall be one hundred (100). Vixie, et. al: RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE), pp16-17 (formatting slightly edited) Given: a/ The size of the .com and .net zones and the hassle associated with doing legacy-style maintenance of zones that size, b/ The desire of customers with the usual bad planning habits (ie. they want DNS delegation changes like yesterday and what is this TTL crap?) ..it is obvious that an administrator of a large, frequently updated zone would want to prepare for dynamic updates. One of the constraints with date-style serial numbers (the only situation when .us residents write dates in the sensible ISO standard YYYYMMDD style ;-) is that the size of the SOA serial number limits the number of zone generations to 100 per 24h period, which might be an issue when using dynamic updates especially if they are being processed automatically. Again, this is not a problem, not something to bother about, and the suits at Verisign will not break things by this. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE I'm wet! I'm wild!