Certain changes to whois will require more work and may result in your domain being locked.
The new ICANN domain name transfer policy goes into effect today, and the key difference between it and the old policy has to do with changes to the domain name registrant.
The old policy was about transferring domain names from one registrar to another. The new policy is about this AND changing the listed registrant’s name, organization or email address.
We went into this in detail in a recent podcast, including a discussion about why this policy probably won’t cut down on domain theft.
Here’s what you need to know:
- If you change the listed name, organization name, or email address on your domain name, an email will be sent to both the previous registrant and new registrant that requires a click to approve the change. Some registrars have changed their terms of service to act as your approved agent for these transfers, so they will not send the email to the previous registrant.
- Registrars will lock the domain from transfer for 60 days after the change, unless you expressly opt out of the 60-day lock before the changes. Note that registrars do NOT have to offer an opt-out of this 60- day lock. You can expect a handful of registrars to lock all domains that are changed, similar to what GoDaddy has done for a long time. If you are buying a domain and want to transfer it to a different registrar, I recommend doing the transfer before changing the whois information. It will take longer to close the sale but will avoid the lock.
TomF says
Ok let’s do an article on who is letting you opt out, and who is Locking you down.
So far points for name.com
JZ says
also who is making themselves the ‘designated agent’ making resulting in basically no change to customers.
John says
I can advise that Fabulous.com have opted out so no probs with them
John Berryhill says
For an additional layer of confusion, ICANN policies apply to gTLDs, but not ccTLDs. Country-code domain name policies are set by the country code registries.
BUT, I am informed that within the last 24 hours, Neustar sent an advisory to registrars in relation to the “ccTLDs that run like gTLDs” such as .co, stating that the ICANN Transfer Policy would be adopted and applied for those ccTLDs.
So… the Transfer Policy will apply to ‘some’ ccTLDs, but not other ccTLDs, just to make things fun.
The Policy is a study in split personality. This gem is worth reading:
“The Registrar must impose a 60-day inter-registrar transfer lock(4) following a Change of Registrant, provided, however, that the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request.”
“MUST” impose, but see the footnote 4, because someone decided to bury an exception to a mandatory statement in a footnote:
“The Registrar may, but is not required to, impose restrictions on the removal of the lock described in Section II.C.2. For example, the Registrar will only remove the lock after five business days have passed, the lock removal must be authorized via the Prior Registrant’s affirmative response to email, etc.”
Aha! So, the Registrar MUST impose a 60-day lock, and may decide it “will only remove” the 60 day lock at some other time as long as it is authorized by an “et cetera”.
What thinking human being could possibly have thought this was in any sense “finished”?
Can you imagine ICANN Compliance enforcement for that?
“You were supposed to impose a 60 day lock, because the registrant did not opt-out, but you only locked it for 10 days.”
“Yes, we remove the 60 day lock after 10 days if we receive an et cetera!”
Pure foolishness.
Wolftalker says
Great overview.
Kate says
Again, what was the problem we are trying to solve here ?
John Berryhill says
The “problem” depends on who you are, or who you have been for the last 16 years.
When ICANN began, there was one gTLD registrar, NSI. They had 100% market share. So, as new registrars were brought online, the largest market over which to compete was in gaining transfers from NSI. For several years, the regular ICANN “we’re doing a great job” slide deck included a graph of NSI’s declining market share over time which, if you think about it, had to be a real kick in the pants if you were NSI. Then again, it was kind of remarkable how long they managed to keep .com priced at $35 a year, even when others were going as low as $12 retail and less, because NSI was “the” registrar.
While domain names were supposed to be transferable among registrars, the exact procedures weren’t very clear. Consequently, in order to keep customers, various registrars became “sticky”. For example, there was one registrar which required a notarized document to be mailed to an address on some Pacific island somewhere within a certain amount of time from requesting the transfer, which practically guaranteed the letter would not arrive before the transfer request expired.
Accordingly, there was an early iteration of the registrar transfer policy which (a) made transfers easier and (b) limited the circumstances under which a registrar could deny an outbound transfer. Because of the fundamentally dumb idea that the transferor to the new registrar was required to self-certify that they were indeed the customer known to the old registrar, this opened up a number of avenues for domain hi-jacking.
Domain hi-jacking, which went on a lot via fake fax certifications sent to NSI, wasn’t considered much of a problem until “someone of importance” had a domain hi-jacked (actually, a largish, for the time, email provider who had connections to ICANN board members).
So then, “something needed to be done”.
However, in parallel with the various layers which had peeled off of the transfer policy effort, the EPP Auth-Code was introduced, which plugged many of the holes which had made hi-jacking fairly simple to carry out. But the transfer policy effort forged on, despite that basic change in the technical landscape.
Inter-registrar transfer procedures had basically reached a point of relative balance, until GoDaddy began implementing a 60 day security hold on internal WHOIS changes to prevent outbound transfers. A common hi-jacking profile is to compromise the victim’s account (by means external to the registrar systems), access the account to change the admin contact email address, and then initiate an outbound transfer using the new email address to confirm the transfer at the gaining registrar. This had been facilitated by the first iteration of the inter-registrar transfer policy, the point of which was to make transfers “easy”.
There was considerable controversy over GoDaddy’s unilateral decision – love it or hate it – to impose a 60 day transfer lock after WHOIS changes. Competing registrars saw it as a new strategy in the “sticky registrar” sweepstakes. GoDaddy and their customers not interested in transferring their domains saw it as a reasonable security measure.
What you are seeing here, in keeping with ICANN’s motto of “Solving Yesterday’s Problems Tomorrow”, is the “resolution” of that argument. In a nutshell, GoDaddy can keep doing what they were doing, but this Policy is really not a policy at all. While including a lot of mandatory-looking language, it is shot through with holes, footnoted exceptions and escape clauses with the overall effect that there is no way in hell you are going to know for sure, on a system-wide basis, what performance to expect from any given registrar in relation to transfers.
None of this policy was formulated on the basis of looking at registrant profiles and expectations. For example, there is a class of registrants who have their one domain name. It is important to them because they run their web site and email through it, but at the end of the day it is something they registered years ago, and don’t want it to go anywhere. Unfortunately, that is exactly the sort of registrant who allows their contact information to go stale, because they do not regularly obsess over the domain name they’ve had for ten, fifteen years, and they are the ones who are most easy to target in the “bad WHOIS data” compliance game. Now, since they no longer have access to that aol email account they used in 2001, they are doubly screwed, given the “safeguards” in the default version of this policy.
On the other hand, you have participants in the domain name secondary market, for whom ease of transferability is essential, and you have their lawyers writing contracts with “time of the essence” deadlines in them, who are likewise going to be screwed by the change in a decade’s worth of assumptions about ‘how things should work’.
The tension between those profiles is reflected in this fine example of committee work. “You must do this… unless you don’t”; “The registrant must confirm… unless they’ve agreed someone else can (i.e. the registrar itself)” and so on.
How transfers will work at any given registrar is simply going to be a crapshoot.
Andrew Allemann says
Domain theft, but I’m not sure how t will do that.
John Berryhill says
ICANN policy processes are not motivated by concerns about registrants, since registrants are not part of the policy loop.
Drewbert says
Never have been, never will be. We nearly got there in 1999, but the IP Constituency and Esther Dyson put a stop to that!
John says
It seems to me that if merely removing whois privacy for the purpose of being able to transfer triggers a 60-day transfer lock itself…
Josh says
@John Good point, should the whois be made public as one does their due diligence when buying or selling will trigger a lock? Question is if someone removes whois triggering a lock to sell a domain can they still push the name internally prior to the 60 days? Because assuming it will not be transferred out it ends up forcing buyer to accept a push if again still available option.
As far as a straight forward transfer from rar to rar with no prior whois changes, nothing changed? Business as usual?
168 says
This could also have an effect on renewal fees if sold close to renewal date and not allowed to transfer to a better reg fee
Enjoy the history Berryhill. Thanks
“there is no way in hell you are going to know for sure, on a system-wide basis, what performance to expect from any given registrar in relation to transfers.”
Spot on.
I’ll have to add this to the disclaimers on my sales agreements.
Drewbert says
So what happens when you mistakenly let a domain expire, and the registrar changes the WHOIS to their data, and then you renew?
Andrew Allemann says
Both would have to approve via email. But companies are working on a workaround for proxy services, which is what most registrars change your whois to when the domain expires.
mcoloso says
i worry about this as go daddy now dont give discounts on renewal i would like to trasfer before the years end…. their price is too much,…..
Robert says
A little confused…if I transfer a domain name successfully…the new domain name owner wants to change the Whois info on the domain name…will I always expect emails forever for these types of changes or just one time per field ?