The ICANN GDD summit 2016 kicks off in Amsterdam, May 16-19, 2016

Not your usual suspects

This summit has a different setup compared to regular ICANN meetings. The main difference is that only the contracted parties will be engaging, i.e. Registrars and Registries and of course ICANN, allowing us to deal with topics that normally aren’t on the agenda.

English: This is a logo for ICANN. Magyar: ICA...

English: This is a logo for ICANN. Magyar: ICANN logo (Photo credit: Wikipedia)

What’s on the menu?
A whole array of topics will be discussed during these three days. Let me give you a little background information regarding some of the sessions.

TLD & Universal Awareness, not to be confused with Universal Acceptance.
Reality has kicked in for the Registries: the registration projections for the new gTLDs have now been replaced by more realistic numbers and everyone agrees that the new gTLDs are in for the long haul. This session, led by the Domain Name Association (DNA), will discuss how we can all create more awareness.

New gTLDs: Getting to the next round
That’s right: there will be a next round. I predict that, somewhere around 2020, you can apply for new TLDs again. There is some talk that this round will be mostly used for brands to apply for their own TLD. On the other hand, ICANN warned 200 brand owners to move ahead with their TLDs as they have made zero progress in the current round. All things considered, it will be an interesting discussion for sure.

Healthy Domains Initiative (HDI)
Botnets, malware, phishing: abuse comes in many forms and is becoming a threat to our industry. The threat being that governments will try to get a grip on this. Governments are usually not technical driven organizations and, even worse, often do not understand technology. In my opinion this makes them the least likely candidate to deal with this “abuse” problem. In conclusion: we need to get ahead of this issue.

Universal Acceptance (UA)
In my opinion this might be the most important topic of the summit. Let me explain the issue with an example.

The TLD .SOCIAL suddenly became very popular in South America a year ago. A lot of people there registered .SOCIAL only to discover that the Internet Service Providers (ISP) in South America where not supporting .SOCIAL. In fact, .SOCIAL was not working at all. Moreover, most of the ISP operators had no idea that a lot of new extensions had been released, causing major problems in all layers of the networking infrastructure.

This problem is still ongoing and ranges from apps not supporting new gTLDS to email servers not delivering email. Even though ICANN cannot solve this problem, the corporation does support the Universal Acceptance Group by any means to get this issue under control.

Room for more.

There is more on the menu during the summit for sure, but in my opinion, the topics mentioned above are the most interesting ones. Nevertheless, I expect the rest of the topics to be pretty good as well. Stay tuned for an update after the summit. Interested in all topics? You’ll find the complete agenda here.

Welcome To Hotel California, Room IRTP-C. The Change of Registrant Policy.

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

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


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.


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 wich 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

Get ready for Realtime Register 2.1

September 10th the new Realtime Register 2.1 system has been released to the OT&E environment. Realtime Register 2.1 ensures compliance with the RAA 2013. We are planning to release version 2.1 to the production environment on Monday September 22th.

We have compiled an extensive Reseller Preparations Guide ICANN RAA 2013 for planning and reference. Make sure to download the Guide, get started with the required actions and forward the information to the appropriate staff members in your organization.

Things you need to take care of:

  1. Check your technical integration
  2. Check your handle management
  3. Check the postal code formats used
  4. Set up your branding
  5. Put your policies on your web sites.

New Realtime Register features:

  • Support for multiple brands
  • Fully editable HTML templates
  • Privacy Protect service
  • Branded registrant validation
  • New REST based API.

Testing environment
Login to the Realtime Register 2.1 OT&E environment at If you don’t have a testing account; please Realtime Register support.

New generic TLD’s
Shortly after the release on September 22th the first new gTLD’s will be available at Realtime Register. We will keep you informed.

News about the ICANN RAA 2013 #3

Realtime Register has made good progress with the preparations for the new ICANN RAA 2013. Below is a summary of important issues to consider. Please note the information sent earlier and available on our blog is still valid. We expect the new contract to be effective at the end of this quarter.

Update registrant information in time
Verification for updates of the registrant is demanded under the new contract. For contacts that are not up to date, we strongly advise you to update these before the ICANN RAA 2013 is effective. Please do so to avoid additional verifications.

Privacy protect
The ICANN RAA 2013 has effect on Privacy Protect (PP) registration of generic domains. Realtime Register has built a low cost system that deals with all requirements. There are two options: reseller supplied data and Realtime Register supplied data.

Realtime Register supplied PP data

  • Easy to set up
  • Small fee per PP registration
  • Redirects complaints or other communication to registrant by Realtime Register
  • No risks, 100% compliant registration

Reseller supplied PP data

  • Pre-acceptance audit by Realtime Register
  • Overall fee for acceptance by Realtime Register
  • Reseller is responsible to provide contact mechanism accepted by Realtime Register
  • Reseller is responsible for executing and compliancy
  • Annual audit reseller by Realtime Register

Testing environment
In the coming weeks we will make a testing environment available for our resellers to become familiar with the new branding options and other web interface changes coming from the ICANN RAA 2013. Please keep an eye out for the announcement.

Data retention waiver
While we are preparing for the roll-out of the new software, we are waiting for the data retention waiver from ICANN. As a registrar established in the Netherlands we are subjected to Dutch law. Some demands in the ICANN RAA 2013 are in conflict with the Dutch legislation about data retention. We expect to receive this waiver in a number of weeks.

Updated general terms and conditions
In the weeks to come we will present you an updated form with the new general terms and conditions which are in line with the ICANN 2013 requirements.

New generics
We are working hard to make the new generics available immediate after the ICANN RAA 2013 is effective. We will inform you as soon as more information is available.

Please check this blog, twitter account and the Domain Manager for updates and the effects the new contract will have on your account.

Changes in policy gTLD´s continued

This is a follow-up on last February´s newsletter about the impact of earlier announced ICANN requirements

Preparations for ICANN RAA2013

A. DNSSEC available
In the Realtime Register Domain Manager DNSSEC options are available for supported TLDs. You might want to test this feature In the Realtime Register (OT&E) environment first. Please note; at this time we support customer maintained name servers only.

B.  Validation of registrants for gTLD’s
The new ICANN policy requires the registered domain name holder (registrant) to validate its details like e-mail address etcetera in order to increase WHOIS accuracy.

Realtime Register will provide a fully brandable environment for this process later on this year.

This is an advance notification to prepare for your communication towards your customers.

Validation for generic domains is triggered on following events:
•  after domain name registration
•  before domain transfer
•  before a contact update.

Consequently the flows of registration and updates will change. Below are the new flows.

Domain name registration flows

Transfer flows

Update of contacts

C. Privacy Protect
Realtime Register will soon offer Privacy Protect services in compliance with the ICANN RAA 2013. Customers having signed the Privacy Protect addendum will be able to offer easy and worry free privacy protect services.

The new contracts, addendums and pricing will be made available soon.

Realtime Register Privacy Protect is a great service to offer to your customers an excellent up-sell opportunity. End user prices are commonly up to $6 annually, per domain. Privacy protect as a paid service is a perfect way to boost your profits.

More news about upcoming changes
Soon you will hear more about:
•   Privacy Protect policy details
•   New Realtime Register contract and addenda
•   Release dates of the changes
•   Details about new gTLD’s