Click the comments link on any story to see comments or add your own.
Subscribe to this blog
31 Mar 2013
Yesterday Verisign sent ICANN a most interesting white paper called New gTLD Security and Stability Considerations. They also filed a copy with the SEC as an 8-K, a document that their stockholders should know about,
It's worth reading the whole thing, but in short, their well-supported opinion is that the net isn't ready for all the new TLDs, and even if they were, ICANN's processes or lack thereof will cause other huge problems.
The simplest issues are administrative ones for ICANN. In the olden days updates to the root zone were all handled manually, signed email from ICANN to Verisign, who manages the root zone, with a check at NTIA, who oversees it under longstanding contracts. As the number of changes increased, more due to added IPv6 and DNSSEC records than increased numbers of TLDs, the amount of email got unwieldy so they came up with a new system where the change data is handled automatically with people looking at secure web sites rather than copy and paste from their mailboxes. This system still in testing and isn't in production yet; Verisign would really prefer that it was before ICANN starts adding large numbers of new TLDs.
The new domains all have to use the Trademark Clearinghous (TMCH), a blacklist of names that people aren't allowed to register. Due to lengthy dithering at ICANN, the TMCH operator was just recently selected, and they haven't even started working out the technical details of how registry operators will query it in real time as registrations arrive.
There are other ICANN issues as well, the process for transferring a failed registry's data to a backup provider isn't ready, nor is zone file access for getting copies of zone data, nor are the pre-delegation testing reqiurements done, and the GAC (the representatives from various governments) could still retroactively veto new domains even after they'd been placed in service.
All of these issues are well known, and the technical requirements have been listed in the applicant guidebook for several years, so it does reflect poorly on ICANN that they're so far from being ready to implement the new domains.
Most importantly, Verisign notes that the root servers, who are run by a variety of fiercely independent operators, have no coordinated logging or problem reporting system. If something does go wrong at one root server, there's no way to tell whether it's just them or everyone other than making phone calls. Verisign gives some examples of odd and unexpected things that happened as DNSSEC was rolled out, and again their concerns are quite reasonable.
An obvious question is what is Verisign's motivation in publishing this now. Since they are the registry for .COM and .NET and a few smaller domains, one possibility is FUD, trying to delay all the new domains to keep competitors out of the root. I don't think that's it. Over 200 of the applications say that they'll use Verisign to run their registries, so Verisign stands to make a fair amount of money from them. And everyone expects that to the extent the new TLDs are successful at all, it'll be additional, often defensive registrations, not people abandoning .COM and .NET.
So my take on this is that Verisign means what they say, the root isn't ready for all these domains, nor are ICANN's processes ready, and Verisign as the root zone manager is justifiably worried that if they go ahead anyway, the root could break.
comments... (Jump to the end to add your own comment)
Add your comment...
Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.
My other sites
© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.