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.
And ICANN should be concerned about another aspect - If ICANN lets this change by Versign pass without inquiry ICANN will greatly weaken its ability to confront a revival of Verisign's Sitefinder. Unless ICANN subjects this new change to the same scrutiny and process that it gave to Sitefinder, Versign is in a good position to assert that ICANN is operating either with an intent to harm Verisign or is simply bumbling along making arbitrary and capricious decisions.
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?)
Posted by karl at January 9, 2004 12:57 AM