To put it simply, registrars have to regularly gather and export some data to a third-party company. Since the creation of this program, we have used a solution which has worked very well for many years, but has started to face limitations due to the increasing amount of domain name registrations. Indeed, generating one of these weekly exports lasted 4 days! It was time to design a long-term and scalable solution.

Let’s see together how we went from 4 days of report generation to 15 minutes, a drastic performance improvement of about +38 000%.

What is the Registrar Data Escrow program ?

As we are an ICANN accredited registrar, we have to send regularly a copy of our gTLD domain names data to an escrow agent, a neutral third party. This is a protection mechanism in case of registrar failure, accreditation termination, or accreditation relapse without renewal. So the data associated with registered domain names is never at risk of being lost or inaccessible.

In concrete terms, for all gTLD domain names that we manage for our customers, we send encrypted files containing:

• The domain name
• The names of the primary and secondary name servers
• The expiration date of the domain name
• Identity information of the domain name contact and nichandles, which are the registrant, the technical contact, the administrative contact and the billing contact (person or corporation name, postal address, e-mail address and phone/fax number)

Authorized escrow agents are listed on the ICANN website. We chose Denic Escrow Services, a European actor, to ensure our compliance with GDPR.

Registrars with at least 400,000 registrations per year are required to deposit a full export once a week, and an incremental the remaining days. For the others, a weekly full export is sufficient. You can find all technical details in the Registrar Data Escrow Specifications.

Basically a report is composed of two types of encrypted files: Domains & Handles (Contacts).

# Domain CSV file
domain,nameserver-1,nameserver-2,expiration-date,registrant-contact,technical-contact,admin-contact,billing-contact
ovhcloud.com,dns.ovh.net,ns.ovh.net,2049-08-01T00:00:00+00:00,EU_contact/123456,EU_xx12345-ovh,EU_xx12345-ovh,EU_xx12345-ovh

# Handle CSV file
handle,name,address-street1,address-street2,address-street3,address-city,address-state,address-postcode,country-name,email,phone,fax
EU_contact/123456,OVH SAS (Klaba Miroslaw),2 Rue Kellermann,"","",ROUBAIX,"",59100,FR,ovhcloud@fake-email.com,+33.123456789,""
EU_xx12345-ovh,OVH SAS (Klaba Miroslaw),2 Rue Kellermann,"","",ROUBAIX,"",59100,FR,ovhcloud@fake-email.com,+33.123456789,""

Why 4 days of generation ?

Domain names have been for sale on OVHcloud since 2000. This ICANN program is mandatory in the Registrar Accreditation Agreement since 1999, and the last official Registrar Data Escrow Specification document has been published in 2009. This is an old requirement that has been implemented in the early days when our Information System was a full monolith with a few domain names in our databases.

At this time, the report generation had been written using a single Perl script doing simple database requests. Over the years, due to the increase of volume and traffic, new teams, new databases, new subsidiaries and new architectures have been created. Data responsibility was divided into different teams like Domain, DNS and Nichandle/Contact. The internal functioning of the report generation did not change though. Without fundamental refactoring, the time needed to generate the report inherently increased over the years.

It was no big deal while it was working well and ultimately did not last more than 7 days, so that weekly exports did not overlap.

But, in the last 2 years, we went from 2,5 days to 4 days. In this situation, if it fails the last day for any reason, we would be unable to generate and send a new one within the week threshold. In the interim, we also have reached a point where we manage about 5 million of domain names, and we intend to keep growing. We had to anticipate and find a long-term and scalable solution, capable of handling 10 times our current domain name amount.

The internal Data Lake

In the meantime, over the years, OVHcloud built an internal Data Lake, a centralized place where internal production data is replicated. It’s meant to be a reliable, secured and efficient platform for storing Big Data.

Then, after agreements with our internal data governance team, authorized teams from all OVHcloud may use this data for data science. For example, aggregation tables can be used by business teams to make decisions or produce legal documents.

OVHcloud current Data Lake is based on Hortworks HDP. On top of this Data Lake, Big Data tools, like Spark, are configured for high performance. Every day, the Big Data tools compute all businesses data to obtain smart and practical aggregation tables.

In this context, as Domain team, we had the perfect replacement platform. Our Data Lake colleagues provide this efficient platform and a set of ready-to-use tools that we can use as a service to solve this Registrar Data Escrow program problematic.

The solution replacement

As previously said, the data which is required for the report comes from multiple teams and multi-region databases. As replications are centralized in the Data Lake, we have a single source that we can request, join and normalize easily. Moreover, as we don’t request the real time production databases anymore, we reduce impact on production performance.

The Data Lake team provides an Apache Airflow platform where we can schedule Apache Spark scripts through Directed Acyclic Graph workflows. Let’s see that, bit by bit:

1. The Apache Spark script is the piece of code that will run in the Spark server, making all the joining and normalization of input data. Execution is massively distributed on Hadoop YARN, so that data is computed and fetched in parallel, assuring a short and constant execution time in the end. This is the central piece of the performance improvement.
2. The script execution is included in a Directed Acyclic Graph workflow, besides other steps like concatenation of result files, working directory removal or uploading final report to Hadoop Distributed File System.
3. Apache Airflow runs the DAG at the related schedule. It also provides an administration UI, in order to manually run the jobs, display logs and so on.

Finally, the concatenated report is fetched from HDFS, syntactically and semantically validated, encrypted and sent to our Escrow Agent.

Conclusion

We can clearly see the improvement of performance on the full report generation in the following table.

Even though it was pure 20 years legacy, the report generation has been working seamlessly for many years and did the job without us noticing. This is important to say, we should keep normalizing the wait for the right moment to refactor something working, even though it’s bad looking code.

Due to increasingly bad performances, now was the time to change the paradigm and find the right long-term and efficient solution. We chose to go with Big Data technologies to build something ready to face the future. As it’s distributed, report generation should take a constant execution time even with a volume increase. This solution should work seamlessly, in turn, for many years.

On the technological side, we can also tell that Spark works really great. By the way, if you did not know, OVHcloud provides a ready-to-use Data Processing platform which uses Spark clusters.

Finally, as you can see, this article is an overview of what we built together with OVHcloud Data Lake team. But, we did not talk about the Data Lake technologies in details. For more in-depth technical content about Spark, take a look at “How to run massive data operations faster then ever, powered by Apache Spark and OVHcloud Analytics Data Compute” and “Improving the quality of data with Apache Spark” articles 🙂

Whereas .com domain names have no restriction, this is not the case for all existing extensions. Obtaining and owning a domain name is associated with legal obligations such as:

• The effective usage of a domain name. For example, a .travel domain name must be related to the tourism industry
• Eligibility requirements. For example, the address of the contact owner of a .eu must be located within the European Union. Or, a .fr domain representing a city name requires to provide a descriptive reason of why the customer wants this domain name

These conditions are set by the extension operator, the registry, and vary according to the extensions while evolving over time.

In this article, we will explain the roles of the different contacts related to a domain name and some examples showing the scope of diversity of eligibility rules.

Contacts

A lot of eligibility conditions are related to contacts. A contact is a legal person (moral or natural) related to a domain name with a given role. It contains information about the identity of the contact, like the name, the address, the e-mail address and the phone number.

There are typically 4 types of contacts: 

• Registrant: the legal owner the domain name
• Administrator: the administrator of the domain. They have the ability to do all possible actions on a domain name (DNS records change, renew, transfer out…)
• Technical: a technical contact has only the ability to change technical data on the domain name like DNS records. They don’t have any influence on the domain lifecycle though
• Billing: the account responsible of all billing related topics such as invoices and payment. By default, it is the account who created the order

By default, the technical and billing contacts are the same as the administrator.

As a customer you can configure the registrant, the administrator and the technical contacts when ordering a domain. The billing contact can be changed later in the OVHcloud Manager.

At OVHcloud, the registrant is unique to a domain name. Changing its properties is local to the domain name it’s related to. Technical and administrative contacts are global though. Changing their properties will change properties for all services using these contacts, like other domain names or web hosting you ordered.

As an individual person who wants to buy a domain to host a blog, you will often provide the same contact information for all 4 contacts. It’s the simple case.

But there are situations when all four contacts may be different. Here are some examples:

	An individual person	A company bought the domain name directly on OVHcloud	A company delegated the domain name through an OVHcloud reseller (the company is not our customer)
Registrant	You	The company itself, with the CEO’s name	The company which is customer of the reseller
Administrator	You	People owning the responsibility domain name lifecycles in the company. Often the CTO.	The reseller company
Technical	You	Operation engineer managing production changes on the website or service using the domain name	The reseller company
Billing	You	The financial service of the company	The reseller company

Data validation

As explained before, although each registry has its own rules in terms of registration, you must provide up-to-date and accurate data to the registrar when you create your domain name. This way, you must provide at least an accurate name, postal address, telephone number and email address. If you don’t comply with this requirement your registration may be cancelled by the registry. Checks on the validity of the data provided by the registrant may take place at the time of registration or during the life of the domain name. In any case, inaccurate data may lead to the suspension or even deletion of the domain name, according to the Registries’ rules. Thus, being the link between the registrant and the registries, the registrar is subject to these different rules and must ensure that the registrants respect them in this matter.

This way, as a registrar we may ask you for specific documents. As an example, the .ie which asks the registrant to upload some specific documents to finalize the registration of your .ie domain name. It may be your VAT number (in case of a legal entity) or a copy of your Irish passport (natural person). Thus, the registry requires the provision of a document from a list in order for the registrant to prove its connection with Ireland.

In this logic, a customer wishing to register a .eu needs to be a European citizen or prove that they are living in the European Union. Due to the Brexit, the conditions of registration evolved, preventing a British citizen living in the United Kingdom to register a domain name in .eu. The only exception being a British citizen residing in the European Union – they are eligible to register for a .eu domain (more info here)

Other registries and therefore extensions are concerned by these particular eligibility conditions to the registration of the domain name. We will give you a last example. Indeed, if you would like to register a .fr domain representing a city name, AFNIC requires you to provide a descriptive reason on why you want this domain and/or supporting documents. If you are the mayor of a municipality and you wish to register a domain name in the name of this municipality, for example, you will have to provide proof of your function. Following the explanations, AFNIC will authorize the registration or not.

Finally, there are some extensions for which the registry reserves the right to cancel the registration because it does not meet the eligibility requirements for registration. As an example, this is the case of .travel. This extension is open to all individuals, organizations and businesses related to travel and tourism. Thus, any participant in the travel and tourism industry can register a .travel domain name as long as it demonstrates a real link with the industry. When registering your domain name, you will only have to accept the special conditions about .travel in the very last step of your order, by validating your affiliation to this industry, before payment is made.

If you find yourself in one of the above cases, you will have to update your contact data when you register your domain name. The manage my contacts feature is accessible at step 3 of the order funnel. You will only have to click on “Manage contacts/owner” in order to modify the Owner’s information or directly create a new profile respecting the eligibility conditions of the extension. Please see below:

And last but not least, as we explained above, there are also data verification after the creation of the domain name. Indeed, we can contact a particular registrant at the specific request of the registry when there is a suspicion of inaccurate data. In addition, we also check annually the data of our customers by sending an email to validate their email address and update their data if necessary. This is the ICANN process called WDRP for Whois Data Reminder Policy. As a registrar, we reserve the right to suspend the domain if a problem is detected during these checks.

Conclusion

Customers have legal obligations and are required to respect the rules provided by the registries. Often, these rules are related to the registrant, one of the type of contacts that is associated to the domain name, but it can also be related to the usage of the domain name.

This series of 3 articles is now finished. It was an introduction to the world of domain names at OVHcloud.

We have a lot of topics to cover. In the next articles, we will talk about technical and business issues.
For example, we can talk about the EPP standard, the most used communication protocol between registrars and registries. And how we test our system when some registries do not provide testing platforms.
We can also talk about the interest of brand protection and the interest of having a domain name for a company (even for offline activities).

See you next time 

As seen previously, OVHcloud is a registrar. As a registrar, our work is very similar to that of a real estate agency. We connect tenants (registrants) with landlords (registries) and get a margin for each transaction. As a registrant, when you order a new domain name, you rent it for a given period (often 1 year), which can be extended until you don’t want it anymore.

In this article, we will show you what happens behind the scenes when you order and manage a domain name. Through a story, we will explain what the domain lifecycle is and how we interact with registries.

Lifecycle

Let’s say you read our blog article about the anatomy of GPUs using Pokémon, and want to start a business selling GPU Pokémon cards. You spent a lot a time thinking about the best domain name to register, and came up with pokegpu.com 

Our story starts on the 12th July 2021, you are ready to start your business. You go to the OVHcloud website and search this domain name.

In the following sections, for readability, periods of 30 and 60 days will be simplified respectively as 1 month and 2 months. It means that when 1st August is increased by 30 days, it will appear as 1st September and not 31th August. 

2021 – Domain Name Registration

First of all, when you search for pokegpu.com, OVHcloud information system will make a check to ensure that:

1. We sell the .com extension
2. There is no ongoing maintenance on the registry backend, Verisign in the case of .com.
3. The domain is available on the registry backend (also known as “Domain Check”)

Luckily, no one seems to want to sell GPU Pokémon cards, so you are free to order the domain name. Once the order is paid, we are able to start the creation of your domain name.

Depending on the extension, you may have to fulfill some requirements, like being a European Union citizen or resident for .eu extension (more on this in the next article). For the .com extension, no need to worry, the extension is available for everyone and there are no specific requirements.

On OVHcloud side, we will create the reference of your domain internally, and communicate with the registry backend by sharing some elements:

• Contacts data: owner, administrator, technical (more details about this in our next article)
• Dates of creation and expiration
• DNS servers (set by default or personalized in the order funnel)

In this creation phase, an anonymized working version of your email is sent to the registry backend, so you can avoid spam by regenerating another if needed. 

If transmitted information is correct, the creation of your domain is finalized in a short time.

Finally, by default, we transparently protect the domain name from unwanted transfers, by sending a command to the registry backend. So you will need to deliberately disable the protection if you want to transfer your domain name to another registrar.

As this is a new business and you are not sure that the company is viable, you decide to disable the OVHcloud auto-renew. It means the domain will have to be manually renewed before expiration, otherwise it will be deleted. Don’t worry, you will be notified before it happens.

It will require a manual renewal before 12th July 2022.

2022 – First Domain Renew

We are now 10 months later (60 days before expiration), the 12th May 2022. Nice, your business works well and you sell your PokeGPU cards all around the world .

But pokegpu.com is almost expired, so you receive a first notification. As you want to keep selling cards, you renew the domain name the 13th May 2022 for 2 years.

A renewal command is sent by our system to Verisign which adds two years to the expiration date.

It will now expire the 12th July 2024.

2024 – Forgotten Renewal

Two years have passed, you now have refocused on another business leaving the sale of GPU Pokémon cards aside for now. And in doing so, even after all the notifications (60 days, 30 days, 15 days, 7 days and 3 days prior to the expiration), you forgot to manually renew your domain name. The domain name expires the 12th July 2024.

This domain name, as well as the other gTLDs, are by default automatically renewed by the registry using the “registry auto-renew” feature. When the domain name expires, it’s renewed on the registry side, and an auto-renew grace period starts for up to 45 days, during which registrars can request the deletion of the domain name so that they are not charged for the renew.

It has to be differentiated from the OVHcloud auto-renew feature. OVHcloud auto-renew is possible on gTLDs extensions but also on the ones which do not support registry auto-renew. Here is a matrix to summarize which cases are possible and how the workflow changes.

Let’s come back to what happened for the expiration of your domain pokegpu.com:

1. As a registrar, when the expiration date was reached, we sent a command to suspend the domain name to the registry. This made the domain name unavailable, as well as the services hosted behind it (email, website…)
2. As it’s a gTLD, we waited for 30 days to let you renew the domain, in order to give you a the opportunity to renew during the auto-renew grace period
3. As it was not renewed during this period, we sent an explicit command to request deletion of the domain name to the registry. The domain name then fell in redemption grace period for 30 days. During this period, the domain name can still be restored from the registry

Now you have two choices:

1. You let it expire and 5 days after the end of redemption, it will be available again for registration by anyone (even by a malicious person)
2. You absolutely do not want to take the risk of losing the domain name and ask for a restore

2024 – Restoration

The domain is suspended and almost lost, it will return to the public domain in a couple of days. Grace period of 30 days expired, but the domain name can be restored. You don’t want to take the risk of having it taken over by someone else, so after some days of thought, you decide to keep your domain name for a little longer and explicitly restore the domain on the 20th August 2024.

This action is very similar to the renewal, but registries often ask for a much more expensive price (about 400% increase for .com). 

A restore command is sent to Verisign, which adds one year to the expiration date and reactivates the domain name. After the operation, the domain name is fully working and related hosted services become available again.

2024 – Secure renew with OVHcloud auto-renew

To avoid such trouble, at OVHcloud we decided to enable the OVHcloud auto-renew feature by default for new domain name registrations.

On the 21st August 2024, you decide to re-enable it. As long as a valid payment method is configured on your account, the domain name will be automatically renewed every year without any action on your end.

You can now focus on your new business with peace of mind  . The domain will be renewed on the 12th July 2025, the anniversary of the creation date, and in the following years until you decide not to. 

Summary

Here is a timeline summarizing what happened:

This timeline happened because a gTLD domain name lifecycle corresponds to the following simplified graph.

1. Domain name is available for registration to everyone
2. Domain name is registered for 1 to 10 years. The domain can be renewed by the customer in this period. If the expiration date is reached without renew, the domain name expires
3. Domain name is expired. It’s suspended and services hosted behind it are not available anymore. When the registry auto-renew feature is activated (to not mix up with OVHcloud auto-renew), registrars have up to 45 days to cancel the automatic renewal. At OVHcloud, we give customers 30 days to renew
4. Domain name is restorable. It’s still suspended and can be restored, which is similar to a renew but with redemption fees
5. Domain name is blocked in deletion for 5 days. It’s still suspended, and domain name will be available again for registration at the end of the period

Conclusion

In this post, we talked about the lifecycle of a single domain name. But the truth is that this story only relates to the lifecycle of a gTLD. ccTLDs belong to a whole new world, often with eligibility rules and a custom lifecycle. 

For instance, .es domain names don’t support automated restore, .it domain names have a renew grace period of 13 days, .pl domain names are not renewed on transfer… All these are special cases we need to integrate in our information system. As as registrar, our role is to lessen these differences by giving a standardized user experience to our customers.

In the next article, we will talk about eligibility rules and how some extensions cannot be owned by anyone.

What is a domain name?

A domain name is a unique human readable identification string that is rented by an individual, a company or an organization on the internet, in order to simplify memorization of elements through domain name servers. For example, domain names can be used to remember an IP address for a web site, an SPF entry for mailing, or a MX mailbox, etc…

The main goal of a domain name is to allow to connect to an internet server by using an easy-to-remember, explicit, and persistent name, instead of its IP address. For example, ovhcloud.com is easier to remember than 54.39.46.56.

DNS, or ‘Domain Name System’ are services whose goal is to translate a domain name to an ip address. It’s a hierarchical system. In this article series, we won’t talk about DNS, and its sophisticated mechanisms. 

We will only talk about domain name. If you are interested in DNS, check our blog regularly. But it’s necessary to understand that domain names are organized in subordinate levels of the DNS root domain, which is nameless. The domain root is the top of hierarchical system.

Below this top level, we find global TLDs (Top Level Domain) like .com, .org, .net, and so on, as well as domain names representing countries called ccTLDs (like .fr for France or .uk for United Kingdom). Then, we can find a label which is the differentiating name of the site such as a brand or an organization, like ovhcloud.

Finally, you can find sub-domains (sub entities of the domain) that can redirect to another ip address like www, docs, or static to have a particular domain for static files on a internet website.
We will talk about different TLDs further in this article.

Basic notions 

ICANN, Registry, Registry backend, Registrar, Registrant: who is who?

To better understand the Domain Names Industry, we must define the various stakeholders.
First, the registry is the entity in charge of the management of the top-level domain names (TLDs). They create TLDs (also called extensions), their relevant rules and work with registrars to sell domains name to customers. As an example, .com is managed by Verisign and .fr by Afnic. Most of the time the registry is a private company, but it may be an association in relation with a government, particularly for ccTLDs.

On another end, there is also the registry backend. This organization manages the top-level domain names from a technical perspective. Sometimes, the registry and the registry backend are different organizations but most of the time they are the same.

A registrar is an accredited organization, like OVHcloud, which is able to sell domain names to the public with the panel of TLDs provided by registries. As a registrar, we purchase a fixed-term license, which can be renewed indefinitely. Thus, we make this license available to our customers, the registrants, who buy their domain name. This way, our work is very similar to that of a real estate agency. Customers don’t rent a house for a year, but a domain name.

In addition, at OVHcloud we combine our registrar role with the registry one for the .ovh that we manage. However, for this special case we are not the registry backend since we use the services of Afnic, like a lot of french TLDs.

The owner of the domain name is called the registrant. It can be a natural person or a company. As a registrant, you can manage your domain name’s settings through the registrar: at OVHcloud, you can do so on the Control Panel. Then the registrar forwards the changes made by the registrant to the registry: the registry’s database can be updated. Indeed, the registrar acts as a link between the registrants, who are its direct customers, and the registry. In this way, the registrant is always in relation with the registrar but never with the registry.

The Internet Corporation for Assigned Names and Numbers, or ICANN, oversees the entire domain name system. It is a non-profit organization responsible for coordinating domain names, IP addresses and DNS, formed in 1998. ICANN brings together people from around the world who work to maintain the security, stability and interoperability of the Internet.
Thus, it promotes competition and develops policies about DNS (Domain Name System) use. This way, it makes sure IP addresses and domains are unique by coordinating these across the world, so we can avoid duplicates. ICANN’s role is to oversee the “universal resolvability”. This means that wherever you are on the network – and hence the world – that you receive the same results when you access the network.
It also accredits Registrars to let us sell domains to the Registrants. In a certain way, ICANN is dedicated to preserving stability on the Internet. However, ICANN doesn’t control content on the Internet but through its role ICANN has an important impact on the expansion and evolution of the Internet.

The different types of TLDs

There are two types of TLDs: gTLD and ccTLD (Generic Top-Level Domains and Country-Code Top-Level Domains).

gTLDs are transnational extensions. The most known is obviously .com, but we also find .org .net .info. The .ovh extension is also a gTLD. Most of the time and unlike ccTLDs, gTLDs do not correspond to a geographical area, but rather to a thematic field. In general, a .tech refers to a website focused on the tech and geek universe while an .org (for organization) generally refers to non-profit organizations. Note that unlike ccTLDs, gTLDs are always composed of a minimum of 3 letters. A ccTLD is composed of 2 letters.
It is important to distinguish the gTLDs called “sponsored” from those that are not. To register a domain name with a sponsored TLD, some conditions must be met. They are enacted by sponsors: they can be private companies or organizations. For example, .gouv.fr is an extension sponsored by the French government and cannot be used by anyone. On the contrary, non-sponsored TLDs are regulated and controlled centrally by ICANN (Internet Corporation for Assigned Names and Numbers). Thus, not being subject to conditions like sponsored TLDs, a domain name with a non-sponsored gTLD can be registered by individuals, companies, organizations, associations, etc.

The ccTLDs, as for them, are logically linked to countries or regions of the World. We find .fr for France, and .be for Belgium for example. Generally, a ccTLD allows to indicate the country of the domain name but some are chosen because of their brand value such as the .tv of Tuvalu and the .io (British Indian Ocean Territory). However, it should be noted that most ccTLDs have linkage requirements that must be demonstrated in order to register a domain name with that ccTLD. Each registry has its own rules for domain name registration, which sometimes implies the provision of specific documents to prove one’s link to the country and/or nationality. This is the case of the .ie registry, which asks the registrant to provide some documents to validate the registration of its domain name.

The multitude of extensions allows to register specific domain names and therefore to stick as well as possible with the use that is made of it. For example, if you want to register a .com or a .fr domain name but the name is not available, you can find what you need in the list of all the existing gTLDs.

Come and purchase your domain name !

Whois

A directory 

As soon as domain names appeared, the need for a directory became essential. There had to be a way to find out who owned a particular domain. Whois protocol has been created, and recently improved with the new RDAP protocol.
When you request whois information on a domain, you can find this information (not exhaustive):

– owner information (administrative, technical contacts)
– creation date and expiration date
– registrar name
– etc…

The representation scheme is often different from one extension to another because each registry chooses its data scheme.

Several tools exist to make whois requests. For example, the ‘whois’ command in your terminal, or our whois for example : https://www.ovh.com/fr/cgi-bin/tools/check_whois.pl 

Debate between public data and protection of privacy

As explained above, depending on the registry, the WHOIS publication rules may differ, especially concerning ccTLDs. Indeed, the ccTLD registries have their own rules obliging the registrar to publish certain information. The gTLDs are subject to the ICANN rules in this matter, which stated that the name, address, telephone number and email address must appear on the WHOIS. Thus, the registrar has to respect a lot of different rules regarding the display of the WHOIS.

In spite of the divergence of rules, the GDPR has come to simplify the publication of the data in the WHOIS since its entry into force in 2018, as we are no longer allowed to publish the personal data of the registrants. This way, the principle of public access has been challenged. At OVHcloud, the only way to contact the owner of a domain name is the Contact Request Form through which a third party can join them directly without seeing their name and email address.

Nevertheless, these are general obligations and it is often up to the registrars to establish the disclosure mechanism themselves. Even today, there is no uniform process to guide the actors involved in this matter.
This is the subject of much debate. On the one hand, there are the privacy advocates, who are happy to see the GDPR applied through the non-disclosure of the data. On the other side, the legitimate access seekers who argue for the protection of intellectual property rights or the protection of the public interest.

Paradoxically, anonymization can also help people who may be scrupulous to hide behind this mechanism so as not to respond to disputes relating to intellectual property or other legal abuse. For example a brand whose domain name in .com has been registered by a third party. Fortunately, there are so-called “abuse” mechanisms allowing legal recourse to be made to the registries.

What’s next?

We explained in this article what a domain name is, the different types of TLDs, who the involved actors are, and the whois tool with its ambivalence.

Now that you know the basics about domain names, let us explain their life cycles. What happens after your domain name is created?

See you soon for a new article dedicated to domain names.

On December 31st, 2020, the UK left the European Union. This withdrawal has many consequences, particularly in relation to domain names. For example, there was an impact on the domain name portfolios of British individuals and companies.

As a response, it’s important to analyze the IT solutions available to British businesses that ensure they are able to survive in the European digital space. To do so, the policies adopted by the various European Registries, whether European ccTLDs or national ccTLDs and other geoTLDs, must be taken into account.

I. .EU : the European TLD

Since January 1^st, 2021, EURid (.EU Registry) no longer allows the registration of new .EU domain names by British registrants. Moreover, from that date, EURid no longer allows the transfer of a domain name to a British registrant.

As a result, the eligibility criteria have evolved. With regard to the European regulations in force on the subject, .EU domain names can now be registered by:

• A European Union citizen, regardless of his place of residence;
• An individual person who is not a citizen of the Union and who resides in a member state;
• A company established within the Union; or
• An organization established in the Union, without prejudice to applicable national law.

The only exception being a British citizen residing in the European Union – they are eligible to register for a .EU domain.

A few dates to remember…

Until June 30^th, 2021: not eligible .EU domains are moved to the so-called “suspended” status. This status means a domain name can no longer support any service (such as website and email) but may still be reinstated if registration data is updated to meet the eligibility criteria. During this period, British registrants can always regain access to their domain name by updating their data with their Registrar.

On July 1^st, 2021, EURid will notify by email all UK registrants and their registrars that their domain name is no longer compliant with the .EU regulatory framework and is moved to the so-called “withdrawn” status. Thus, the domain name is not in the zone file and cannot support any service. During this period, the only possible operation to reactivate a “withdrawn” domain is a ContactUpdate. After updating the contact or creating a new contact with valid data, if the registrant wishes to reactivate his domain name, it will be necessary to make a legal transfer. This is a procedure carried out by EURid’s legal department which will validate the reactivation of the domain name.

On January 1^st, 2022, all the domain names with a “withdrawn” status, will be revoked. They will then become available for general registration. For security reasons, their release will occur in batches.

Now that we’ve analyzed the European regulations, let’s focus on the ccTLDs of the Member States.

II. ccTLDs of the Member State of the European Union

As mentioned above, each Member State of the European Union is free to lay down the rules of its choice regarding eligibility. This leads to many disparities in the Union. In addition, the ccTLDs are subject to the jurisdictions of the countries concerned and therefore to their law. On the other hand, the eligibility criteria of a ccTLD are subject to the rules of the Registries and so they can change at any time. This must be taken into account when purchasing a domain with a ccTLD.

As the principle of the free movement of goods also applies to domain names, territorial restrictions cannot apply to European companies and citizens. However, they do apply to legal entities whose registered office is located outside the European Union and to natural persons who are not European citizens or who do not live in a Member State.

Thus, due to Brexit, British individuals and companies are no longer allowed to register a ccTLDs domain related to the following European countries:

• .BG – Bulgaria : art. 3 of the terms and conditions for domain name registration and support in the .BG zone and the sub-zones,
• .CZ – Czech Republic : art. 12.6 of the Rules of Domain Names Registration under the .cz ccTLD,
• .FR – France : press release from AFNIC,
• .HU –  Hungary : art. 1.1.1. of the Domain registry Policy,
• .IT – Italy : art. 1.2.3.6) of the Assignment and management of domain names in the ccTLD .it,
• .LV – Latvia : art. 3.1. of the Policy for acquisition of the right to use domain names under the top level domain .lv.

On the other hand, British individuals and companies will be able to keep their domains in some European countries such as:

• .AT – Austria : art. 1 of the General Terms and Conditions,
• .BE – Belgium : art. 1 and 3 of the Terms and Conditions for .be domain name registrations,
• .DE – Germany : §3(4) of the DENIC Domain Terms and Conditions,
• .DK – Denmark : Terms and Conditions for the Right to Use a .DK Domain Name,
• .EE – Estonia : art. 3.1.1, 4 and 4(1) of the .ee Domain Regulation,
• .ES – Spain : .ES Terms and Services (in Spanish),
• .FI – Finland : Domain Name Regulation 68/2016,
• .HR – Croatia –only legal entities are allowed to register a domain name with proof of a British ID number– : art. 15 of the Organisation and Management of the National Top-Level Domain, as amended by Article 5 of the Ordinance on Amendments to the Ordinance on the Organisation and Management of the National Top-Level Domain,
• .IE – Ireland –additional conditions may be required– : art. 3E of the Registration and Naming in the .IE Namespace Policy, Process, Procedures, Rules & Guidelines,
• .LT – Lithuania : Procedural Regulation for the .LT Top-Level Domain,
• .LU – Luxemburg : art. 2 of the Domain Name Charter under .lu,
• .MT – Malta : art. 4.3 of the Domain Name Registration Policy,
• .NL – The Netherlands –additional conditions may be required– : art. 1.1. of the General Terms and Conditions for .nl Registrants (1 May 2019),
• .PL – Poland : .pl Domain Name Regulations,
• .PT – Portugal : art. 11 of the .PT Domain Registration Rules,
• .RO – Romania : Rules for Registration,
• .SE – Sweden : Terms and Conditions of Registration For the top-level domain .se.
• .SK – Slovakia –eligibility rules recently updated– : art. 2.1 of the Terms and Conditions of Domain Name Service in .sk Top Level Domain,

What about the British ccTLD .uk and its SLDs ?

Despite Brexit, the conditions of eligibility remain the same. European individuals and legal entities can still register a .UK domain name under the same conditions as before December 31^st, 2020. All the British SLDs managed by Nominet are not affected.

III. geoTLDS of the Member State of the European Union

We also need to consider geoTLDs. These extensions are linked to a city, a region or a cultural community. Most of the time, some eligibility rules should be respected and/or sometimes a content control or cultural interest may be required.

First of all, let’s focus on the geoTLDs with no restrictions (and so no territorial restrictions). British individuals and companies will still be able to register domain names with the following extensions:

• .BRUSSELS – Brussels : art. 2.1, .BRUSSELS/.VLAANDEREN 2012 Terms & Conditions,
• .IRISH – Ireland : art. 1 of the General Registration Policy,
• .KOELN / .COLOGNE – Koeln / Cologne : General Registration Policy for .KOELN and .COLOGNE,
• .VLAANDEREN – Vlaanderen : art. 2.1, .BRUSSELS/.VLAANDEREN 2012 Terms & Conditions.

With the following extensions, they will also be able to register domain names without territorial restrictions, however an additional criterion is required:

• .BARCELONA / .BCN – Barcelona – a link with Barcelona is required and a content control applies : art. 2.1, Normativa de registre de .barcelona,
• .CAT – Catalonia – languages and cultural conditions apply : art. 2.2 of the .CAT Domain Name Registration Policy,
• .EUS – Basque Country – a link with the Basque Country is required + languages and cultural conditions apply : art. 2 of the .eus Registration Policy,

And last, there are also geoTLDs with territorial restrictions, so British people will not be able to register domain names with the following extensions:

• .ALSACE – Alsace – alternatively, cultural interest is required : art. 2.1, Politique d’enregistrement .alsace,
• .BAYERN – Bayern : art. 3b, Domain Name Registration Policy,
• .BERLIN – Berlin : art. 5.1, Policy for the Registration of .berlin Domain Names,
• .BZH – Britanny – alternatively, cultural interest is required : Conditions d’enregistrement du .BZH,
• .CORSICA – Corsica – alternatively, cultural interest is required : art. 1.2, Politique d’enregistrement du .CORSICA,
• .HAMBURG – Hamburg : art. 5.1, Policy for the Registration of .HAMBURG Domain Names,
• .MADRID – Madrid – alternatively, a direct or indirect link with Madrid is required : art. 4.1.1 del Contrato de registro de nombre de dominio “.MADRID”,
• .PARIS – Paris – alternatively, a direct or indirect link with Madrid is required : art. 2.1, .PARIS Registration Policy.

Registry eligibility rules are sometimes complicated and differ from Registry to Registry, and thus from ccTLD to ccTLD… However, we hope this blogpost will help you better understand the impact of Brexit on domain names, whether you are directly impacted or not.

Come and purchase your Domain at OVHcloud !