As a result of the Registerfly disaster, ICANN has been collecting proposals for Registrar Data Escrow Services that ensure that if a registrar goes out of business, the registrant’s and doman data is protected and available to ICANN. Let us take a closer look at what actually happened at RegisterFly that caused ICANN to issue this RFP and then look to see if the proposed solution is a viable and workable answer to this problem.
Registerfly failed to provided the services that they charged registrants for, they failed to pay their suppliers (registries etc) so that in the end their ICANN accreditation was revoked. In order to take care of the registants’ needs, ICANN asked Registerfly to provide their registrant’s data to them.
Initially RegisterFly started out as a reseller of eNom and occasionally other registrars, such as Tucows. They built their own system that connected them to to the registrar’s APIs. Much of their programming was actually done by the owner, Kevin Medina, himself. When RegisterFly bought an ICANN accreditation, they switched to using the Logicboxes system and later migrated to the Tucows OpenHRS Registrar solution. RegisterFly also offered their own domain privacy service, ProtectFly. After RegisterFly went out of business, their customers were taken over by GoDaddy.
In order to understand the problem with whois data, we need to take a closer look at how the registries, the entities that operate the TLDs work, and how whois data is stored. For the generic Top Level Domains (com/net/org/info/biz), there are two types of whois databases operated by the registry: Thick & Thin. A thick registry such as .INFO will hold all the contact infomation for a domain in the registry database itself and a thin registry will only hold a reference to the registrar’s whois that contains that information. Both types of databases contain the nameservers, create date, last updated date, expiry date as well as some status information. The problem: The largest generic TLDs, com & net, are thin registries and rely on the registar to hold and provide the contact information for a domain.
So the Registrar Data Escrow Service is supposed to obtain data from the registrars on a regular basis in order to hold it in escrow in case there is an operational problem with a registrar or the regulator (ICANN), for whatever reason, needs access to the data.
One of the problems the RFP fails to address adequately are whois privacy services. This is a problem that RegisterFly registrants were also facing, since we know of some cases where RegisterFly apparently a) used their own whois information on orders processed on behalf of registrants and b) the original registrant information was not stored when whois privacy was purchased. A Data Escrow Service with optional fields for the registrars that provide whois privacy service does not seem sufficient to address this potential issue.
Now one thing that really strikes me as odd, is that the escrow service and whois privacy are not offered by the registries. The thick registries already hold the correct registrant data, and I am hoping that they already backup their data on a regular basis. The only part that is missing is some sort of whois privacy flag, that displays other contacts in the whois output. As for com & net, while the registry recently migrated to the protocol normally used for thick registries (they migrated from RRP to EPP), they still do not hold the contact information on the registry level.
.ORG (PIR/operated by Afilias) actually is an example of a successful migration from a thin to a thick registry – even the biggest challenge (migrating all the registrar data into the registry whois database) was completed without major problems. So why is VeriSign not taking the opportunity to fix this problem once and forever by converting the COM/NET registry to a thick registry. Who knows who the next registrar will be to go belly up and how many domain owners will be affected this time.
(images from sxc.hu)