ICANN Plans for Disaster: A Registry Failure

By Larry Seltzer  |  Posted 2008-08-01 Print this article Print

It's hard for most of us to imagine VeriSign failing, but for some of the other companies in the registry business, the possibility is real. The Internet Corporation for Assigned Names and Numbers is finally taking steps to figure out what to do if a registry fails.

Users spend little time thinking about Internet registries like ICANN or VeriSign because they don't deal with them directly. Perhaps they should.

VeriSign and the other companies that operate the top-level domains on the Internet are critical infrastructure. At least some of them are. What if one of them was to fail somehow? This is the question ICANN is asking with its proposed gTLD Registry Failover Plan.

In June 2001, the gTLD operators established a Registry Failure Task Force to look into this question, but nothing much happened until last year. Perhaps it's just a coincidence, but interest rose once more during the development of the Registerfly scandal, in which a registrar failed and had to be decommissioned by ICANN. gTLDs, in case you're wondering, are "generic" top-level domains, such as .com and .org, as opposed to ccTLDs (country code top-level domains), such as .uk and .cn. The administration of ccTLDs is left to their various national authorities. Some, like .tv (Tuvalu) and .me (Montenegro) have commercialized their domains.

You can find a complete listing of all TLDs and who runs them on the IANA (Internet Assigned Numbers Authority) site. Clearly the biggest and most important is VeriSign, which operates the .com and .net domains. One would presume that VeriSign is in good shape, but what about the others? When's the last time you saw a domain name with a TLD of .pro, .jobs or .museum? In fact, last year there was some concern for a while about the viability of the company that owned the .travel registry. One might ask, "Who would notice if it failed?" but ICANN has to ask more than that.

What sorts of events could precipitate a registry failure? In the case of .travel, it was a financial problem at its parent company. However, other things are possible. The registry, if poorly designed, could be hacked. A natural or man-made disaster could take out physical facilities. In some cases (e.g., nuclear war takes out the city in which a registry is housed), we all just might have better things to do than to bring .whatever back up.

The plan, such as it is now, defines who at ICANN and the registry are relevant to the process and what they shall do. It defines how communications with the public will be handled. The ICANN crisis management team will be tested at least once per year.

There is special consideration for data escrow and data security. Since last November, registrars have been required to escrow their data, including private registration data, with an authorized service. Registries are also required to do this, and I think the requirement goes back further. If things go bad enough, ICANN might recover the data from the escrow service and bring it back online elsewhere.

ICANN has been thinking about these matters a lot more lately than it had in the past, and this is a good thing. I can't imagine what it was spending its time on before this, but it wasn't as important.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com's Security Center Editor Larry Seltzer's blog Cheap Hack.


Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel