What happens at the registrar

Many domain name registries do not sell names directly; you have to go through a registrar. For example, in France, Article L45-4 of the French Postal and Electronic Communications Code specifies that “domain names are allocated by registries, through the intermediary of registrars”. For TLDs (top level domains such as .com or .pizza) which are under contract with ICANN, these contracts also oblige the holders to go through a registrar. So what exactly does the registrar do?

The interface with the registry

The least visible part of the registrar’s work is interfacing with the registry. This may be done through EPP (Extensible Provisioning Protocol), through a web-based interface, or through a network API (Application Programming Interface) specific to the registry. The major registrars, which process huge numbers of operations every day, generally prefer EPP, which is standardised¹ and used by a large number of registries. In this way operations can be completely automated. The smaller registrars often use a web-based interface (if it exists) and their operations are generally manual. So large registrars have to develop or acquire an EPP client². The remainder of this article refers mainly to these large registrars.

Since every registry has specific policies³, this interface also requires users to read some documents such as, for the .fr domain, the Procedures Guide.

The interface with the user

But the most visible part of the registrar’s work is obviously that which comes face-to-face with the user, the person who is going to file and then manage domain names. Just as the registry may offer several interfaces to its registrars, (EPP, web-based, API, etc.), so may a registrar have several interfaces for its clients. In general these are web-based interfaces and APIs⁴.

Web-based interfaces

Unlike the registry, whose web-based interface for provisioning (creating and managing domain names) is accessible only to its registrars, a small and expert group, the registrar has to design a web-based interface for a very large public. This is a difficult task, involving issues such as UX (user experience throughout the provisioning operations), ergonomics, universal accessibility even in the case of persons with disabilities of various kinds, etc.

System security is one of the important points to be dealt with. One of the main threats facing the domain name holder is the risk of name hijacking, when a malevolent party takes control of a domain name belonging to someone else. Such misappropriation may be the result of the holder’s negligence, but it can also come from a security failing on the part of the registrar. Making an information system reliable and safe is no easy task.

Registrar’s API

Large registrars often have clients with many domain names to manage, so in many cases these registrars provide an API (Application Programming Interface) allowing their clients to develop their own programs and avoiding the need for these clients to perform tedious manual operations on their numerous names. To give a specific example, we’re going to use Gandi’s API (this does not imply any particular recommendation of this registrar⁵). These APIs are not standardised, and it will be necessary to read the documentation of the one you wish to use (in this case, Gandi’s). Like most APIs, it requires the prior creation of a key for authentication. In the case of Gandi, this is done under the heading “Security” of your account with the registrar. Then, requests can be made in any programming language: HTTP requests must be made by adding an authorization field containing the key to the header. From then on you are limited only by your imagination; via the API you can create domains, change contacts, change name servers, etc. Detailed examples are shown in the annex to this article.

Other activities of the registrar

A registrar does not confine itself to its technical interfaces with the registry and the user. It must also provide assistance to users, which is a difficult and time-consuming task when the client calls to say “it doesn’t work”.

And there are also legal activities, for example to respond to abuse such as the registration of names with malicious intent.

Some registries require accreditation from registrars, in other words they must demonstrate minimum technical, financial and other capabilities. Such is the case, for example, of registrars accredited by ICANN for registration in TLDs under contract with ICANN.

We have only touched on domain name registration here, but it should be noted that most registrars provide other services, such as DNS hosting (authoritative servers), website hosting, email, instant messaging with services like Matrix, etc.

But it’s more complicated than that

We must first explain that there are two kinds of domain name registries, “thin” and “thick”. Thick registries are those where all the social data (name and contact particulars of the holder, contacts, etc.) are in the registry. The registrar may have a copy of the data that it has sent, but this is not obligatory. A person wishing to obtain information on these social data need only ask the registry, via a public web-based interface for example or via the Whois or RDAP protocols⁶. The thick registry model is the simpler, conceptually. Furthermore, the vast majority of TLDs such as .fr, .nl or .org are  thick registries.

So everything’s OK and we don’t need to take account of the thin registries? Not really, because the biggest TLD of all, .com, is a thin registry, as is .net. So a registrar often has to deal with these thin registries. The principle on which they operate is that, for a domain name, the registry knows only the list of name servers, the name of the registrar, and some metadata such as the date of creation. The rest, and in particular the social data, are with the registrar⁷. This means the registrar too must offer query services such as Whois or RDAP⁸. You see this separation between the registry and the registrar clearly when you use a Whois client. With the Whois client in the command line, information is sought on twitter.com:

% WHOIS twitter.com

Domain Name: TWITTER.COM

Registrar WHOIS Server: whois.corporatedomains.com

Registrar: CSC Corporate Domains, Inc.  

Creation Date: 2000-01-21T16:28:17Z

…

Then the registry’s response is ended and we have the response of the registrar, to which the Whois client was redirected. This time, we have the holder’s identity:

Domain Name: twitter.com

Creation Date: 2000-01-21T11:28:17Z

Registrant Name: Twitter, Inc.

Registrant Organization: Twitter, Inc.

Registrant Street: 1355 Market Street

Registrant City: San Francisco

Registrant Country: US

…

A case where this separation between registry and registrar is seen clearly is when a legal action with the registry eliminates or alters a domain without the registrar’s being informed. In this case we see the two databases (registry and registrar) giving contrary information.

Speaking of databases, if the registrar works with a thin registry, it will need such a local database to store social information (contacts), that the registry does not have. But with the thick registries? In theory, a registrar could subcontract everything to the registry and do without the database completely. This would be simpler for the registrar but, in practice, many registrars work with at least one thin registry (typically .com) and, in any case, wish to have their own database, for example to enter other information on their clients. So a database must be managed (with all that that entails, in particular backups) and care taken to ensure that it is synchronized with the registry. Besides, it is to facilitate this synchronization that the registries often have a mechanism allowing the registrar to recover the list of domains that it manages. One might think this unnecessary – after all the registrar knows which domains it manages! But it’s useful if a technical problem leads to the two databases becoming desynchronized.

Conclusion

A registrar, as we have seen, is not a pure intermediary that can content itself with relaying client requests to the registry. It performs numerous functions, some of them delicate.

Annex: use of a registrar’s API

This annex, designed for programmers, shows some examples of the use of a registrar’s API, in this case that of Gandi. To find out more, we recommend consulting their documentation. First of all, we create an API key via Gandi’s web-based interface. In the examples, we will suppose that it is 12345 (the real ones are obviously more complex).

Let’s start with the simplest thing, recovering the list of my domains. The great advantage of a HTTP API is being able to use the programming language of your choice. Let’s see first with two programs in the command line, curl and jq:

% curl https://api.gandi.net/v5/domain/domains \

               --header "Authorization: Apikey 12345"

We recover a long JSON object. We’ll use jq so as to have only domain names:

 % curl --silent https://api.gandi.net/v5/domain/domains \

            --header "Authorization: Apikey $12345" | jq '.[].fqdn'

"cyberstructure.fr"

"internautique.fr"

…

We’ve asked jq to run through the whole of the recovered JSON table and then to extract the field fqdn.

Of course, using the API for just one domain does not make much sense. In principle, we’d make loops on the lists of domains that we wish to manage.

An example in another language? We’ll use Python, its standard json library and the HTTP library Requests.

r = requests.get("https://api.gandi.net/v5/domain/domains",

                  headers={'Authorization’ : ‘12345’})

d = json.loads(r.text)

for domain in d:

    print(domain["fqdn"])

A case where the API is very important is for managing DNSSEC, the system for strengthening authentication in DNS using cryptographic signatures. When we add or remove cryptographic keys, we must alert the registry, through the registrar. With Gandi’s API, the information on the key has to be sent in JSON. If we’ve created keys with the dnssec-keygen utility, we can proceed as follows in Python:

f = open(keyfile, 'r')

key = None

for line in f:

    match = re.search("^%s\.?\s+IN\s+DNSKEY\s+256\s+3\s+([0-9]+)\s+(.+)$" % domain,

                      line[:-1])

    if match:

        key = """{

        "algorithm": %s,

        "type": "zsk",

        "public_key": "%s"

        }""" % (match.group(1), match.group(2))

f.close()

if key is None:

    print("No ZSK key found in %s for domain %s" % (keyfile, domain),

          file=sys.stderr)

    sys.exit(1)

r = requests.post(Gandi.URL + "domain/domains/%s/dnskeys" % domain, data=key,

                  headers=[as before]

Note that we now use the HTTP POST method, not GET. Gandi’s API follows the usual REST (REpresentational State Transfer) principles. So to delete a key, it’s the DELETE method:

r = requests.delete(Gandi.URL + "domain/domains/%s/dnskeys/%s" % (domain, keyid),

                    headers=[as before]

^{1 – RFC 5730 and a few others.}

^{2 – But not everything can be done via EPP. For example, the registrar cannot recover the list of its domains, nor manage locks on sensitive names. It must therefore use another method, like an API specific to the registry.}

^{3 – And rightly so. For example, the ccTLDs (country-code top-level domains) such as .de or .bf depend on the laws and customs of their respective countries.}

^{4 – EPP could be used but it is clearly too complex for most clients.}

^{5 – But this API is particularly well documented, with numerous examples in different programming languages.}

^{6 – Sometimes grouped under the abbreviation RDDS (Registry Data Directory Service).}

^{7 – This model had been chosen by ICANN in the hope that it would allow the issue of users’ privacy to be dealt with. The idea was that registrars would compete to provide the best protection of personal data and that users concerned about privacy would go to the registrars offering the best protection. In practice, this was a failure, partly because certain laws, such as the EU’s GDPR, impose minimum protection and do not allow the market to offer less, and also because it is difficult for users to choose a registrar, and vague promises such as “we protect your privacy” cannot be interpreted in any obvious way.}

^{8 – In practice, ICANN imposes such Whois and RDAP servers on the registrars that it accredits, even if they work only with thick registries. That said, in view of the importance of .com, most registrars deal with at least one thin registry.}