From Karl Auerbach's CaveBear Blog
Yesterday the following announcement from Verisign appeared on the NANOG mailing list:
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....
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.
There is no reason to believe that ICANN was forewarned of this change.
This announcement generated more than 50 comments on NANOG's mailing
list. At the end of of the day the consensus seemed to be that if properly
contained within Versign's own TLD slave servers, that this change would not
have a negative impact on the net.
There are a couple of assumptions in that consensus conclusion - the most
important being the assumption that the only servers that use the zone
created by Verisign are Versign's own servers for .com and .net.
There is good reason to question that assumption - I know that I have heard
unsubstantiated rumors over the years that several large organizations run their
own copies of the .com and .net zones in their own servers.
It has been pointed out to the IETF that one of the major components of web-surfing
delays is DNS resolution time. Two large ISPs, AOL and Earthlink, have
been actively advertising about the fast response of their services. It
would make a great deal of business sense for AOL or Earthlink to run such
mirrors so that they could ensure that their users receive fast DNS responses.
What might happen if that assumption does not hold true? Let's posit
the hypothetical that AOL or Earthlink mirrors the .com and .net
zones on its own servers for use by its own users. This mirroring has, in
fact, been part of those rumors I mentioned. Now, if my hypothetical were
true, Verisign's change could cause AOL or Earthlink to become unsynchronized
from the correct contents of .com or .net. That would be
"instability" in spades for a lot of internet users.
Sure, I am positing a hypothetical example. But fiction, particularly
when driven by strong business incentives, often becomes reality. Did
anyone bother to verify beforehand whether Versign's unilateral change was
really, truly, and sincerely confined exclusively to Versign's own herd of slave
servers?
In addition, there is usually a right way and a wrong way to do things.
The "right way" (or in IETF terms, the "Best Current
Practice") to make a zone file "serial number" go backwards has
been set forth by the IETF - in section 7 of RFC2182.
Now, who or what is the body that is tasked with the job of ensuring the
stability of DNS? In an acronym: ICANN.
We can't fault ICANN that it was not informed in advance.
But we can fault ICANN if it does not immediately respond, as it did in the
case of Verisign's "Sitefinder" with a stop demand, a formal technical
inquiry, and a formal written report.
Now, it is obvious to many of us that Verisign, which does have many very
capable technical people on its staff, is capable of making this change without
harm. But to come to that conclusion we have to accept, on nothing more
substantial than blind faith, the assumption that the only existing slave
servers are Versign's. And we have to make the further assumption that
Versign's smart and capable people will actually make the change in the right
way and not take shortcuts. We've seen examples of what
bad things can happen when skilled people take shortcuts.
But just because something is obvious to a few skilled techies does not mean
that there ought not to be a prior review and issuance of an opinion by ICANN,
the body that has been established for the specific purpose of ensuring the
stable operation of DNS.
Postscript: Verisign's new method, because it uses a 32-bit time
measured in terms of seconds since January 1, 1970 GMT, reminds us that an
event more formidable than Y2K, 19-Jan-2038, 03:14:07 AM GMT, is only 34 years away. Given the rapid ossification of the Internet, is 34 years really beyond the event horizon?) [CaveBear Blog]