Tucows will follow TechOps subcommittee recommendation for domain transfers as ICANN figures out what to do.
Here’s the thing about GDPR and domain name registrars/registries: if they wait for ICANN to figure out how to address GDPR, it will be too late to make the necessary changes to comply with the law. GDPR enforcement goes into effect in just 23 days.
One registrar that has been at the forefront of making changes to comply with GDPR (and has been stating them publicly) is Tucows (NASDAQ: TCX), which owns both Enom and OpenSRS. It is the second largest domain name registrar in the world behind GoDaddy.
The company recently posted about changes it will make to its domain name transfer process as a result of GDPR.
As I’ve written about before, if you can’t access a domain registrant’s email address, you can’t do a transfer under the current methodology mandated by ICANN.
Tucows is adopting the proposal put forth by the TechOps subcommittee of the Contracted Party House inside GNSO. It removes the gaining registrar’s Form of Authorization requirement.
Today, if you were to transfer a domain name to a Tucows registrar, you would provide the transfer authorization code to Tucows. Tucows would then send a Form of Authorization email to the current registrant listed in Whois to verify that they authorize the transfer.
Once this verification is complete, the losing registrar begins its process. This includes sending an email to the domain registrant to ask if they’re OK with the transfer. If they don’t respond within 5 days, the transfer is completed.
Tucows is eliminating the first Form of Authorization. Once you provide the authorization code, Tucows will skip directly to sending the transfer request to the losing registrar.
This creates a security risk because of how losing registrars are currently required by ICANN to respond to transfer requests. If they send an email to the registrant and the registrant doesn’t respond, the transfer goes through.
The TechOps committee has proposed a solution to this. It would allow the losing registrar to deny the transfer if the domain owner doesn’t affirmatively confirm the transfer.
How many registrars will start denying transfers like this starting May 25? It’s hard to tell. Big ones might, but small registrars are mostly unprepared for GDPR changes.
Of course, there are common sense security measures that domain owners can take to protect their domains as Whois and the domain transfer system is in flux.
Be sure to set transfer lock on your domains and add two-factor authentication to your domain name registrar account. Also, check to see if your registrar offers added transfer protection.
Volker Greimann says
I agree that the TechOps group proposed an excellent and workable solution, but with the glaring loophole of requiring all registrars to implement it, it poses a security risk unless summarily adopted by ICANN and made mandatory binding (temporary) policy.
If some registrars do not implement it correctly, their registrants are more at risk from unwanted transfers than those customers of registrars that did implement it.
While the auth-code provides some form of security, it alone is not sufficient as too many entities in the chain between the registrar and the registrant may gain access.
TechOps, and Tucows are open to suggestion on this issue, but the solution proposed appears to be the best we can do for the moment. There is also broad recognition that we’ll need to kickoff a new transfer policy development post GDPR.
Also, TechOps will try and get some Registrar best-practices out, like making sure your auth-codes are all fresh.
Very few ICANN domains should be affected as only 7% of the world’s population are EU citizens. Further this only applies to registrars that have a presence in the EU and it only applies natural persons not legal persons.
Those registrars with a presence in the EU need to get explicit granular consent from all their EU citizen registrants for (a) escrowing data and (b) WHOIS and any 3rd party authorised privacy services. That shouldn’t be too difficult for the majority of those registrants as registrars have a direct relationship and have to email verify WHOIS under the current agreements.
Just hiding the WHOIS won’t cut it as the consent needs to be explicit and granular.
It is likely the overwhelming majority of registrants would be happy to have the security escrow provides and continue with their current arrangements either open public WHOIS or authorised 3rd party privacy service.
This leaves a very small percentage of registrants that either do not respond or do not consent. For that very small number of domains why not show an “EU GDRP consent withheld” message in the WHOIS email field.
Then 97% and probably more like 99% of transfers can continue as normal.
On the ones with “EU GDRP consent withheld” in the WHOIS why doesn’t the gaining registrar ask the registrant to supply the email address in the WHOIS (which now can’t be seen) together with the authcode?
The gaining registrar then sends the email address to the losing registrar who then checks it against the one he has on file and then confirms to the gaining registrar either it matches or it doesn’t.
If it matches the gaining registrar sends the notice out as per normal
Or is this missing something?
Andrew Allemann says
Unfortunately this applies to all registrars, not just ones in the EU.
How does it apply to all registrars?
Suppose China passes a law that all ownership data in the WHOIS has to be publicly available and failure to do so results in $100m fines for registrars.
What does a US registrar do risk paying the EU fines or the Chinese fines?
Surely this remains an EU jurisdiction only problem unless ICANN chooses to extend it? GDPR issues for registrars with a presence in the EU are far wider than published WHOIS.
True, as it was explained to me even the non EU rar’s have or will adopt this policy thus affecting us all 🙁