Why does the 60-day "Change of Registrant lock" exist after changing a domain's contact details?

Question

There are few circumstances, enumerated by ICANN at https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en in the Why is my registrar refusing to transfer my domain name? section, in which a registrar either may or must refuse to transfer a domain. Some of these involve 60-day windows after certain events.

One of these, the 60-day lock that registrars are permitted to implement after a domain is transferred from a different registrar, is already discussed at Why do we have to wait 60 days between each domain transfer?, and a rationale provided: by throttling the rate at which a domain can be transferred between different registrars, the maximum number of different registrars involved in a (swiftly-discovered) domain hijacking is kept low, which minimises the amount of work involved in reconstructing the sequence of events after a hijacking and returning a domain to its rightful owner.

However, another one of these 60-day rules is a 60-day "change of registrant" lock that registrars are required to impose after any of the contact details of the registrant change. This lock does not seem to be justified by the above explanation, so I assume there is a different rationale behind its existence - but I can't see any. What's it for, and why is it mandatory when the domain transfer lock is at the registrar's discretion?

Answer 1

If someone manages to change the registrant contact details on your domain would you be happy if they then immediately transferred it away? Or would you prefer some sort of cooling off period so that any malicious actions can be undone?

That is the point of a 60 day lock after the change of (only certain) registrant details.

Answer 2

There are "outs" for that rule that ICANN allows. Many Registrars have added a way for Registrants to opt out of that lock.

Why does that rule exist? It is a method to try to prevent domain hijacking. I don't think most Registrars or even Registrants have asked for that type of lock, since there are many other, more effective ways to minimize domain hijacking, like adding two factor authentication.

Answer 3

The issues are linked, for the reasons explained below.

But let us please first go back in history to put things in context, and I will be mostly targeting gTLDs and .COM/.NET in fact:

• when the registry/registrar split started, the protocol used to communicate was then RRP (see RFC2832); as you can see in its section 4.3.10 the transfer command was used by the new registrar... without providing anything except the domain name
• this of course just by itself mean that abuses can happen, so ICANN drafted a policy mandating registrars to ask prior consent to the current registrant (or administrative contact); this was in fact a nightmare for registrars as they had to parse whois output to grab email addresses to be able to contact a registrant before launching the transfer command; this policy evolved over time and its latest version mandates specific email messages that the prospective registrar has to sent, again to registrant or admin contact and he needs to get back specific positive acknowledgement before proceeding with the transfer
• even with this danger, or to mitigate it, many registrars did send emails to their customers when they are notified of an outgoing transfer (they get the information from the registry), since by default a transfer takes 5 days during which the current registrar can oppose it (if it does nothing, the transfer get approved, but can also be explicitely expedited before it if the current registrar sends the appropriate command to the registry, some of them did provide this feature to their customers); so transfers could be blocked, but only during this 5 days period
• in parallel, RRP got progressively replaced by EPP (see STD69); in this protocol the transfer goes a little differently: the idea is that each domain name has a "password", called authInfo in the protocol, defined at creation time (and later updated as wanted) and normally under control of the registrant (which was in fact not really what happened on the field, registrars often took care of it just by themselves); the transfer command required the prospective registrar to send the authInfo along with the domain name, the idea being that the prospective registrar got hold of this "password" because the person starting the transfer would either been the registrant or somone having received the authInfo as given by the registrant
• even with this newer protection, the ICANN policy did not change, and hence registrars will still contractually mandated to send and get positive authorizations by email before even attempting the transfer, and even if they got the authInfo (this would still be mandatory by the protocol).

Even with all of these "protections", it happened on the field that "many" domains got stolen for various reasons, and people doing so went from one registrar to another, which made both the investigations and the eventual cancellation of the operations complicated because if a domain went from X to Y then Z, the resolution could not be done from Z back to X, it would still need to involve Y, so that made things long and complicated.

Hence the 60 days blackout after any creation or transfer: it gives the registrant that think its domain has been stolen enough time to contact the registrar to at least freeze the domain while investigating the dispute, before the domain name moves again.

This ICANN policy is detailed here: https://www.icann.org/resources/pages/registrars/transfers-en (and, as a consensus policy, it applies immediately and without the need of explicit reference anywhere, to any registrar or registry accredited by ICANN, so this concerns gTLDs only).

Only very recently (December 2016) did ICANN extend its policy also to registrant change, especially its email. You can view the redline here: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf

Note that, contratry to the delay after transfer/creation, the delay after registrant change is an opt-out, so the registrar can forfeit it if the customers ask for it.

Why did ICANN add that? Because otherwise you have a clear loophole as the whole procedure above depends on the current registrant (or administrative contact) to reply to some email to allow to start the transfer.

Imagine you want to steal some domain like that: you need both the authInfo code (to give to the future registrar) and to control the email address to be able to reply to the "FOA" (the formatted email to gather authorization). By default, you can not. But if you find a way to connect to the registrar panel with the correct authorization (by any kind of other attack, like a phishing one), you could change the correct registrant which gives you two things:

• first you will easily be able to get the authInfo code, as all registrars have a system to give that to the current registrant
• then, you could put any kind of email you want, so that you are able to receive there the FOA and reply to it.

If all of the previous succeeds you can start the transfer. And this will be difficult to troubleshoot if the former registrant suddenly complains because there are 5 parties involved: the registry (the policy allows the registry to have a role in handling disputes about transfers), the former registrar, the new registrar, the current registrant, and the previous one.

Now, with the newest ICANN policy, even if you manage to change the registrant information, you will need to wait 60 days to start the transfer. Again, this gives more time for the former registrant to detect there was a problem (the registrar may have notified him that something changed on its account, or for advanced users they may monitor the whois output and see there a difference...), and to correct it. Or at least to freeze the transfer, to make sure the problems do not get worse.

For a final point, note that all of this can change in the near future and come back to some saner setup, like at the beginning (piling policies and protocols one of top of the other to resolve a problem gives you only more problems). Newer European regulations (GDPR) have an impact on both whois and transfers. In short the consequence is that it makes very hard for a prospective registrar to send email to the current holder and get its approval. ICANN's current proposal on the table is to use RDAP tiered access for it, which might work but will certainly take time and is indeed more of a workaround around a broken system than really a revamp of the system (and previous attempts by ICANN to change the whole system were going in directions even more wrong, such as creating a global whois content repository). Another solution was put on the table by some working group inside ICANN: https://www.icann.org/en/system/files/files/gdpr-comments-contract-party-techops-icann-proposed-compliance-models-08mar18-en.pdf

In short, it will mandate the current registrar, not the prospective one to get acknowledgement from the current holder. The prospective registrar would just need to start the transfer, again and still with the authInfo required by the protocol and retrieved from the customer starting the transfer.

Answer 4

As noted in the Policy on Transfer of Registrations between Registrars, registrars are required to obtain authorization from the Registered Name Holder before carrying out a transfer. As such, these contact details serve a security purpose: they are the details that a registrar will use to confirm authorization before carrying out a domain transfer.

Hence the lock serves to help avoid domain hijacking. Without the lock, somebody who has acquired your login details to a registrar could change your domain's contact email to their own, request a transfer, and then receive the confirmation email themselves and use it to authorize the transfer. With the lock, they can't immediately carry out such a hijack; if they request a transfer without changing the contact details, they won't receive the confirmation email, and if they change the contact email, then the lock kicks in and gives you 60 days to notice that something is wrong and correct it before the hacker gets to steal your domain.