Privacy by default account setting.

Today we introduce a new account setting called:”Default Privacy Protect setting”, which you can access by clicking here.

Setting disabled.

When selected, domain name registrations and transfers will not use our privacy service automatically. This is how it used to work for years.

Setting enabled when free (and available)

When enabled all domain name registrations and transfers will automatically use our privacy service. Regardless if you use WHMCS, our API or the domain name manager.

A list of available TLDs that can be used for this service is located here.

We keep recommending this service as it is unknown if gTLD registries will continue to publish the data in the WHOIS or not. Several large gTLDs will no longer publish the WHOIS, similar to how we will operate our WHOIS server. But some of them most likely will keep publishing registrant data.

Enabled (when available)

Same as above but also will use privacy services that are not free of charge. Please check the price list in your account if that is the case.

Registration

When you register a domain name you can override your account settings if required. Select the desired action from the drop-down menu.

Current Customers.

At the moment the default setting is not active, as mentioned earlier. Due to the new ICANN contractual regulations that have been rushed out of the door on 17-05-2018 this week, we are reviewing the option to turn this on for all customers. I apologize in advance for any inconvenience this may cause.

Post GDPR gTLD Transfers

Update: 25-05-2018

The procedure below is now live as per the ICANN temporary spec. I observe that not every Registrar was aware of the below situation. If you cannot transfer out your domain name(s) advise the gaining registrar to stop parsing WHOIS data and trying to send FOA emails to the registrant or admin contact, this will no longer work.

 

The new procedure has been communicated last week by ICANN to all registrars. To view this communication click here,

 

 

As mentioned in a previous blog the WHOIS will change drastically over the next few weeks.

At the moment when you start a transfer through the API or domain manager, our system sends an FOA to the registrant or the admin contact based on our contractual ICANN requirements. Once the FOA has been approved by one of the above contacts the transfer is requested at the registry,

I and other colleagues at the ICANN Registrar Stakeholder Group (RrSG) discussed the issues and we came up with the following a solution, a solution that has strong support. More details about this solution and the letter to ICANN can be located here.

Transfer solution post-GDPR

We will no longer send the incoming FOA, the auth code is sufficient to request the transfer on a registry level.

The losing registrar will still be required to send the outgoing FOA, the registrant can agree or decline the request. If there is no response from the registrant the transfer will be processed automatically after 5-7 days unless the losing registrar not acknowledges the transfer and cancel the transfer on their side.

Domain names that are set to transfer prohibited will not be transferred, if your customer wishes to transfer in or out, the transfer lock needs to be removed prior to the transfer. We recommend setting your domain names to transfer prohibited and regularly change the auth-codes for the domain names under your management for security reasons.

The above-described transfer process should not be to complex for most resellers, as it works somewhat similar how the larger ccTLD registries operate.

Recommended domain name security reading

A Registrant’s Guide to Protecting Domain Name Registration Accounts a report from the ICANN Security and Stability Advisory Committee (SSAC)

SSAC Advisory on Registrant Protection: Best Practices for Preserving Security and Stability in the Credential Management Lifecycle

Domain theft?

Though at first glance it seems the above changes might lead to more domain theft. This is counter mitigated due to the fact that the WHOIS info will no longer contain registrant data and email addresses. This info is usually an attack vector for hackers who steal domain names, with this attack factor no longer in play we expect to see fewer cases of domain theft.

Key transfer changes post GDPR summary.

  • Transfers will continue to require a valid authorization code; just like EU ccTLDs
  • The gaining registrar will no longer be required to send a Form of Authorisation (FOA) to the registrant, again most likely there is no WHOIS info to create one.
  • The losing registrar will continue to send an FOA (aka outgoing FOA) that allows the registrant or admin contact to ACK (acknowledge) or NACK (not acknowledge) the transfer;
  • If there is no action/response, the transfer will auto-ACK by the registry after five days from initiation of transfer;
  • Registration information will not be transferred as part of the IRTP-C, registrants will independently re-enter transfer information with the gaining registrar. This will include entering into a registration agreement with the new registrar as it is now.

 

 

The ICANN WHOIS system is gone, the process for a GDPR compliant WHOIS has started!

 

After twelve months of endless discussions and a looming deadline, ICANN received information from the Art 29 Working Party. 

The EU Data Protection Authorities will not grant ICANN forbearance regarding the May 25th deadline when it comes to the WHOIS. Again the DPA’s re-confirmed their advise towards ICANN and does not deviate much from the advice they have provided ICANN since 2000.

The full press release from ICANN and the Article 29 WP letter can be read here.

Now that it is official there will be no forbearance regarding WHOIS, which was a silly request to begin with, registrars must shift into gear to get the WHOIS GDPR compliant.

Our solution will look like the screenshot below, though the below is subject to future change, I do not expect our GDPR solution will change drastically.

 

We will continue to display the country code and state field (if provided), due to the fact that it might be relevant for trademark lawyers.

The solution mentioned above is a mix of what ICANN has sent to the Art 29 WP, there is some advice incorporated from the ECO playbook. Last but not least we cherry-picked some elements from the WHOIS output solution by the Dutch Registry SIDN.

SIDN does not publish personal data of the registrants for many years now, so we have a great deal of experience with such WHOIS output and as a result, we have many operational procedures and solutions in place.

 

Reseller lookup tool
Our Reseller lookup tool is available here. We will also mention the link to this tool in the WHOIS output of the Realtime Register WHOIS server.
This tool allows people to look up the domain and the relevant reseller contact information.

As a data processor, we are limited in our role due to data protection laws, and we must refer to the data controller (our reseller) when it comes to domain name inquiries.
I think our lookup tool will be of great assistance for Law Enforcement Agencies, Trademark Lawyers, etc.

Most of our Dutch resellers will be very familiar with the above concept, as reseller data plays a significant role in the WHOIS for .NL domain names.

I expect that the WHOIS will become less relevant on May 25th and will have an effect on transfers.
Expect a blog post about the transfer details within a week.

Also, this blog describes the WHOIS server of Realtime Register, not the WHOIS servers operated by thick registries all over the world. It is possible that while we at a registrar level do not display personal data, a Thick WHOIS registry continues to show the data of your customers in their available public WHOIS…

Realtime Register GDPR TLD matrix is now public.

Last week we received a lot of positive comments regarding our GDPR TLD matrix. And we had a lot of requests to get access to the matrix.
As a push to create more GDPR awareness, we decided to publish our API on the website for the public, including the GDPR TLD matrix.

You can enter the matrix here.

Keep in mind the matrix has been developed with the Realtime Register processes in mind and in some instances cannot be merely be pasted and copied.

One comment which we received a lot last week was:”wow there are so many unknowns.”
While that observation is spot on, it is the reality we all have to deal with in the TLD industry, and it is very annoying that at this stage we still do not have clear answers.
Most registries still have to determine their position on what they will publish in the WHOIS and what not.

So feel free to use the GDPR TLD Matrix.If there is a sense amongst registrars and registries turning the GDPR TLD Matrix into a collaborative effort, feel free to contact me.

I expect to update the matrix over two weeks and add a few more categories plus more information.

Realtime Register Release and New Features

This page is dedicated to the relevant changes, added features and fixes of the Realtime Register front and back end. Please visit regularly to stay up to speed. The API Changes are documented in more detail on the API Docs Change Log pages and additional documentation. Please note, login is required.

26/09/2017
Improvement: Privacy Protect v2 allows transfer out without exposing registrants date. In preparation for GDPR.
Bugfix: Denic, some unsupported Unicode characters in address contacts will now give the proper error message.
Improvement: NicIT, NS check now inline with registry policy.
Improvement: NicIT, Client hold option removed.
Bugfix: Fixed check on additional properties.