.COM and .NET: Thick or Thin?

Gavin Brown is CentralNic's Chief Technology Officer. Originally published on CircleID.

The fallout from the failure of RegisterFly has been largely
addressed as an issue of regulation and enforcement. ICANN needs to
enable registrants to transfer their domain names away from
RegisterFly, or to "bulk transfer" all of RegisterFly's sponsored
domain names to another registrar. However, RegisterFly has control of
all the customer data so it's impossible to match registrant to domain
name, in order to release the all-important AuthInfo code.

The Registrar Accreditation Agreement (RAA) requires that registrars
place this customer data into an escrow system with ICANN, so that in
the event of a business failure at a registrar, ICANN can distribute
AuthInfo codes to registrants as required. Therein lies the problem:
ICANN has not historically enforced the escrow obligation, and in any
case, if a company has failed, who exactly is going to take
responsibility for updating the escrowed data? It seems to me that the
problems that have arisen as a result of RegisterFly's collapse has as much to do with the design of the "shared registry system" for the .COM
and .NET TLDs than they do with ICANN's failure to enforce the RAA.

I realised that many of RegisterFly's customers have had no trouble
getting their domain names transferred out. Those customers who have
registered domains under .ORG, .INFO or any of the other gTLDs, or
under most ccTLDs, are able to transfer their domains out of
RegisterFly's control with no problems. Why? Because most of those TLDs
are run as thick registries, whereas .COM and .NET are thin.

What's the difference? Simply put, in a thin registry, the contact
details for a domain registration (namely the registrant, admin,
technical and billing contacts) are stored at the registrar, and the
registry's whois server only shows basic domain information, and
provides a referral to the "registrar whois" which then shows the
relevant contact data. Conversely, in a thick registry system, the
contact details are stored at the registry level, and are shown in the
"registry whois". There is no "registrar whois".

The use of the thin model for .COM and .NET places an additional
(and in my opinion) unnecessary layer of complexity to the system - not
only does it impose upon registrars the requirement to operate and
manage a whois system, but it also increases the effects of a
registrar failure on registrants.

As we have seen with RegisterFly, when a registrar fails, the only
protection that registrants have is a legal contract between ICANN and
the registrar that the registrar will place customer data in escrow.
This is essentially a legal solution to a database design flaw. As we
have seen, it isn't even that good a solution since a legally binding
contract with a failed business is no more valuable than the paper it's
written on.

However, with a thick registry, if a registrar business fails, all
the data required to facilitate the transfer of domain names is already
available to the registry operator, and so the failing registrar's
compliance is not required.

We have seen that thick registries can scale perfectly well: .ORG
and .INFO, both operated by Afilias, are run on the same thick registry
platform which holds over 9 million registrations. Registrars retain
the same degree of control over the customer data they collect: the
registry acts as a repository for data managed by the registrars.
Moving .COM and .NET to the thick registry model would eliminate the
need for registrar data escrow and provide greater security for
registrants when registrars fail. It would also simplify the shared
registry system by employing the same model across all gTLDs, reducing
the potential for confusion on the part of Internet users.