You might have heard some horror stories about the upcoming change of registrant policy, effective starting this August.
Some of these stories tell a tale about certain hotel California Registrars, easy to check in your domain names, but you will never be able to transfer them out.
Hotel California (Photo credit: Wikipedia)
Now as a member of the ICANN group, IRTP-C IRT, who actually spend a lot of time drafting this policy, let me be the first to debunk some myths regarding this policy.
Transfers will not be impossible, but they will be harder if the current email address is incorrect due to the fact that you will need to update the email address and this will trigger a change of registrant procedure. Depending how well or badly your Registrar implements this, it will either be a rather simple procedure or a complete nightmare. So if you plan to transfer your domain names, now is a good time to do so. As the policy currently does not apply.
The following will trigger a Change of Registrant procedure
- Change of email address
- Change of the first name and last name
- Change of the organization name
Requirements
What are the requirements for a Registrar when the above scenario is being triggered.
– Process the change of registrant through a secure mechanism
– Send a confirmation to the old and new registrant.
In a nutshell, that is actually what the change of registrant entails.
Scenarios
First of all, do you as a reseller want to process the change of registrant or do you want us, Realtime Register do it?
We at Realtime Register look at it this way and though I am going to mention some numbers here, they are by no means set in stone. So they are only examples for now.
Scenario One; Let Realtime Register do the work
Imagine a reseller has 1000 domain names in his portfolio. How many times would there be a change of registrant where the domain name remains with the same reseller? I expect maybe once a month?
So in this scenario, you would like to have Realtime Register to provide the secure mechanism. First of all, you do not have to invest any money or time in a secure mechanism if you do not offer one, second if you do have one you do not have to check if your secure mechanism is up to par with certain RFC’s and best practices that deal with usernames and passwords and security in general. As this is actually the spirit of the policy.
Using the Realtime Register secure mechanism works as follows. You change the registrant for a domain name, Realtime Register will send a confirmation email to the old and new registrant, as soon both agree we will process the change and send a confirmation to the old and the new registrant. So make sure your branding is up to date.
Scenario Two; DIY
Scenario one might be problematic if you have a lot of domain names. Most likely this will create support pressure. If your control panels that you offer to your customers/registrants are secure then you can become a designated agent.
The solution, become a designated agent. This solution can be used by most hosting companies who offer control panels to their customers to allow domain name operations and or other services and always require a registrant to log into a secure environment.
A designated agent according to the policy is an entity that can operate on behalf of the old and new registrant if they acquired explicit consent from the old and new registrant. So in order to be able to process these changes, you must make sure that your registration agreements contain this language and make sure your customers have given consent. Most likely you want to record this in the case of an audit you can easily demonstrate compliance with the policy.
This also means that you need to make sure that control panels you offer to your clients are secure enough. You do not have to start offering two-factor authentication (even though that would be nice) as one-factor authentication is also considered to be a secure mechanism. Provided you use best practices.
Best practices and common sense
Best practices do not allow usernames and password to have a length of 4 characters, so that is a no go. Microsoft has a good article about strong passwords which you can read here.
Now with the above in mind, a change of registrant can be executed as follows. You send the change of registrant to our system through the API and you will send an extra API tag so our system knows that you acquired consent from the old and new registrant. The domain name will be updated and we will not send emails where the registrants have to agree to. The email that the change has been processed to the old and new registrant will still be sent as this is a requirement of the policy. Dutch Resellers might find this notification requirement similar to the Dutch Registry notifications who have a similar process in place.
The above procedure will also be available through the domain manager.
In the weeks to come, I will post more on how we are going to deal with transfers, privacy protect and other fun stuff.
The entire IRTP-C policy is located here
Last but not least, as mentioned earlier, it will be critical that you have up to date data and working email addresses for your customers in the future. So avoid a lot of hassles and make sure the data is correct. At Realtime Register things will be made easy, I can, however, not predict how other Registrars will implement this policy. So make sure that your data is up to date if all of your domain names are not at Realtime Register.
If you have any questions, let me know and shoot me an email at support@realtimeregister.com