[ALAC] Root Zone KSK Rollover

[Alan Greenberg]

Although there may be some similarities (certainly in the 
end-result), the reason is very different.

In the the case of the KSK Rollover, we had several unknowns. We had 
no idea how many servers did not have DNSSEC enabled (which meant 
they would not be affected) nor how many had it enabled and had the 
new key. Nor did we know how fast service would react if there was a 
problem. The last estimates were that a VERY tiny fraction of users 
would be affected, and that proved to be true.

With Y2K, there was abundant evidence that in the absence of an 
intense work effort, there WOULD be problems - it was easy to see 
that a system that only stored two digits for the year would sort 
them out of order when once there was a "00". And a system that 
subtracted 1900 from the full year would suddenly have a 3-digit 
result. And there was plenty of code that did not recognize properly 
that 2000 was a leap year (so Feb 29, 2000 was another hurdle when 
some of us held their breath). Even many systems built in the 
mid-1990s were going to fail.

Issues were not just software (where in many cases, the source code 
no longer existed) but hardware clocks which did not expect the 
change. It was estimated that for network equipment (primarily voice 
I think) only 50% produced prior to 1996 would function properly. And 
where the hardware would work, the billing might not.

And unlike with DNSSEC (where you could opt out consciously or 
unconsciously be not using DNSSEC), you could not opt out of the year 
changing on Dec 31.

In the end, there were relatively few problems, but that was because 
of an unbelievably intense effort that went into fixing potential 
problems or replacing or decommissioning systems.

Alan

At 13/10/2018 12:45 AM, Kan Kaili wrote:
>
>Sounds like the terror story happened just before the year 2000 ...   :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20181013/22e00ea5/attachment.html>