If you’ve already registered a domain name, you’ll have seen the various stages: choosing a registrar, creating an account if not already done, connecting to the registrar’s online interface, looking for a free name that meets your criteria and complies with the registration rules, selecting it, providing the requested information, getting your credit card out and you’re done. Just a few minutes later and your name is ready for you to work on your online presence.
But what goes on behind the scenes? The purpose of this article is to set out the various stages. Admittedly, you don’t need to know any of it in order to make a success of your digital project. But apart from perhaps satisfying your curiosity, this article provides useful information for a better understanding of what goes on and the consequences for you. Since not everything happens everywhere in the same way in the huge world of the Internet and domain names, this article will focus mainly on the registration of a .fr domain name.
First of all, we must recall that behind the registrar organisation whose client you are, is a registry, which is the organisation in charge of a domain such as .fr, .bf or .gay. The registry is responsible for maintaining a database of sub-domains of this domain, with information on the holders and contacts, making the names accessible via the DNS protocol, and allowing searches for information on a name via systems such as the Web, Whois or RDAP. In the case of .fr, this registry is Afnic. Article 45-4 of the French Post and Electronic Communications Code provides that “Domain names shall be allocated by the registries, through the intermediary of the registrars”. It is these registrars that are the ‘external face’ when you reserve a domain name. Let’s look now at the rest of the process.
The registrar and the registry must communicate with one another. The registrar asks the registry whether the name tested by the user is free and available for registration. The registrar then asks the registry to place the name in the database. This communication follows a standardised protocol called EPP, Extensible Provisioning Protocol. What is a protocol? It’s a set of precise rules that two applications must follow in order to communicate on a network such as the Internet. For example, you can read this article because your browser and Afnic’s server speak the same protocol, HTTP (Hypertext Transfer Protocol). Unlike the very well-known HTTP, EPP is a discrete protocol used basically between domain names registries and registrars. It provides several services, such as asking the registry whether a name is free, asking it for information on a registered name, creating a new name or deleting one. Note that the EPP server, unlike the HTTP server that is behind https://www.afnic.fr/, is not publicly accessible. Various security measures restrict access to accredited registrars.
By the way, I mentioned that EPP was standardised. What does that mean? It means that the protocol, the set of rules that must be followed by the client (the registrar) and the server (the registry), are formally described in a document developed and validated by a standard-setting organisation, in this case the IETF (Internet Engineering Task Force). For EPP, the document in question is known as “RFC 5730”. It is freely available without charge but requires some effort to read and understand.
So there is communication between the registrar and the registry using EPP over the Internet. And once the registry has received, say, a request to create a name? The registry’s application carries out various checks, then includes this name in the database and there we are! One more .fr name.
Note that the process is entirely automatic. People are sometimes surprised that a particular domain name should have been registered, and wonder “How can Afnic have accepted this name?”- as if an employee checked each name and decided subjectively on its merits and risks. Such manual verification would be far too slow for clients’ requirements, and too costly in view of the price of a domain name. That doesn’t mean that all names are acceptable. Article 5.3 of the Rules for Registration in .fr stipulates that “the registration and renewal of domain names shall be performed on the basis of declarations made by the applicant and under the applicant’s responsibility”. Other registries have similar rules, and it is rare for a registry to manually verify names prior to registration.
But this does not mean that there are no tests at all. The registry automatically tests the syntax of the name. A domain name such as “thing amabob.fr” with a space will be refused, for complex syntactical reasons. Similarly, in many registries there are lists of terms that are prohibited or registration of which is subject to additional constraints. With .fr, this is the case, for example, of the terms subject to prior review, such as names of communes or terms associated with racism, Nazism, etc.
(While on the subject of rules and prohibitions, note that there are procedures for resolving possible disputes regarding domain names. There are always the courts of course, but there are also private procedures. Since they are manual and not carried out strictly by a software, they naturally take longer and are more costly.)
Right, so now the domain name is in the database. Now no-one else can register it. (If you’re the holder of a name, you should think about security: see Afnic Issue Paper No. 9). But entering it in the registry’s database is only part of the operation; you also have to allow the outside world to access the information in the database, or in any case some of it. This is the role, for example, of two other protocols, Whois and RDAP (Registration Data Access Protocol) which provide information on domain names. Both provide more or less the same service, reading the database and formatting the result for sending to the applicant, the difference being basically technical. Whois is older (it was standardised in “RFC 3912”), while RDAP is the future (its standard consists notably of “RFC 7482” and “RFC 7483”). Unlike the EPP server, the Whois and RDAP servers are most of the time accessible to all, without authentication. In both cases, the client is able to obtain some of the information from the server (the registry). I say ‘some’ because in France, the Loi Informatique & Libertés (Data Protection Act) limits what can be done with personal data, and a request to Whois might not therefore give you all the information that the registry has, for example, on the person holding a domain name. It is not a question of anonymity (the registry always knows the person’s identity) but rather of restricted dissemination of information to the public. Apart from Whois and RDAP, most registries also offer a Web interface for querying the database (often wrongly referred to as ‘whois’).
But another way to obtain the information stored in the database is no doubt more important: the DNS (Domain Name System). It may even be the prime motivation for domain name registries. The person or organisation registering a name does not do so simply to store information, as is the case, for example, with trade mark registries. Above all, this organisation or person wants the domain name to be operationally useful, so that we can visit the website that uses this domain name, for example. This is the role of DNS, a crucial protocol in the operation of the Internet. It allows information to be recovered very quickly and effectively on the basis of a domain name. For example, it is via DNS that a browser wishing to visit https://réussir-en.fr/ will retrieve the IP address associated with the name réussir-en.fr (it is currently 2001:41d0:305:2100::6cfb). In order for all the DNS servers to work together so that this browser can obtain the technical information necessary to connect to the server, the registry must deploy a group of authoritative DNS servers. ‘Authoritative’ means that these servers know the exact list of sub-domains of a given domain and can respond with certainty to all requests concerning this domain. So the authoritative servers for .fr, managed by Afnic, know the list of all the names under .fr and can therefore respond authoritatively “this name is managed by such and such a server” or “this name does not exist”. The authoritative servers are updated every ten minutes in the case of .fr by a program of the registry which extracts the changes from the database and transmits them to the servers.
The reliability of these authoritative servers is crucial. If they are out of action, no names under the domain that they serve will function. One of the essential tasks of the registry therefore is to keep these servers running around the clock, 365 days a year, despite physical breakdowns, network outages and various attacks. Each server whose name appears in the DNS is thus composed of several physical machines located in different places.
(A technical aside: not all DNS servers are authoritative servers. Some are resolvers, which don’t know any domains themselves but know who to ask. These resolvers are typically managed by your Internet access provider or by the IT department of the organisation you work for. These resolvers remember the questions recently asked and the corresponding replies, as a result of which they sometimes transmit slightly dated information. So not every change in the registry will be immediately visible everywhere. For more on the functioning of DNS, watch the Afnic video.)
The model presented here assumes a registry that does everything itself, but some registries make use of various levels of sub-contracting. Some registries sub-contract part of the authoritative servers, for example to ensure diversity, in token of robustness. Such is the case of .fr (with server names, those that include an ‘ext’ are external to Afnic, and a cryptographic technique, DNSSEC, ensures that they do not alter the data). Some other registries sub-contract the entire DNS hosting. And some also sub-contract the management of the database, with the associated services such as EPP or RDAP, retaining the political, legal and commercial responsibilities.
The registry has many other responsibilities. If it simply stuck to putting information in a database, it wouldn’t be such a big deal. But it also carries out many other tasks, of which this article presents only some. Let’s wrap things up with one of these tasks, and a crucial one at that: data back-up. Equipment may break down, causing files to be lost. A successful attack may also lead to the loss or non-availability of data. The registry must therefore carry out frequent back-ups, verify them, store them securely, etc. (Some registries, such as .fr, are also subject to a data escrow obligation, entrusting periodically a copy of the data to a third-party body to prepare for any eventuality.)