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.