Si vous avez déjà enregistré un nom de domaine, vous avez vu les différentes étapes ; choisir un Bureau d’Enregistrement (BE), s’y créer un compte si ce n’était pas déjà fait, se connecter à leur interface Web, chercher un nom libre correspondant à vos critères et aux règles d’enregistrement, puis le sélectionner, donner les informations demandées, sortir votre carte de crédit et c’est fait, quelques minutes après, votre nom est prêt, vous pouvez travailler à votre présence en ligne.
Mais que se passe-t-il derrière ces actions ? Le but de cet article est de vous présenter les différentes étapes. Bien sûr, vous n’avez pas besoin de savoir cela pour mener à bien votre projet numérique. Mais cet article, outre la satisfaction de votre curiosité, pourra vous donner quelques informations utiles pour mieux comprendre ce qui se passe, et les conséquences que cela a pour vous. Comme tout ne se passe pas partout de la même façon, dans le vaste monde de l’Internet et des noms de domaine, cet article se centrera surtout sur l’enregistrement d’un .fr.
D’abord, il faut se rappeler que derrière l’organisation dont vous êtes client·e, derrière le Bureau d’Enregistrement (BE), il y a un registre, qui est l’organisation en charge d’un domaine comme .fr, .bf ou .gay. Le registre a la responsabilité de garder une base de données des sous-domaines de ce domaine, avec les informations sur les titulaires et les contacts, de rendre accessible les noms via le protocole DNS, et de permettre la recherche d’informations sur un nom via des systèmes comme le Web, whois ou RDAP. Dans le cas du .fr, ce registre est l’Afnic. L’article 45-4 du Code des postes et des communications électroniques français prévoit que « L’attribution des noms de domaine est assurée par les offices d’enregistrement [registres], par l’intermédiaire des bureaux d’enregistrement ». Ce sont ces bureaux d’enregistrement qui sont la face visible de votre démarche de réservation d’un nom de domaine. Voyons maintenant le reste du processus.
Le BE et le registre doivent communiquer. Le BE demande au registre si le nom que teste l’utilisateur est libre, et enregistrable. Ensuite, il demandera au registre de placer le nom dans la base de données. Cette communication suit un protocole normalisé, nommé EPP, pour Extensible Provisioning Protocol. Qu’est-ce qu’un protocole ? C’est un ensemble de règles précises que doivent suivre deux logiciels pour communiquer au-dessus d’un réseau comme l’Internet. Par exemple, si vous pouvez voir cet article, c’est parce que votre navigateur Web et le serveur Web de l’Afnic parlent le même protocole, HTTP (pour Hypertext Transfer Protocol). Contrairement au très connu HTTP, EPP est un protocole discret, utilisé essentiellement entre registres de noms de domaine et bureaux d’enregistrement. Il offre plusieurs services, comme demander au registre si un nom est libre, lui demander des informations sur un nom enregistré, créer un nouveau nom, et en supprimer un. Notez bien que le serveur EPP, contrairement au serveur HTTP qui est derrière https://www.afnic.fr/, n’est pas accessible publiquement. Diverses mesures de sécurité restreignent son accès aux BE accrédités.
Au passage, j’ai dit qu’EPP était normalisé. Cela signifie quoi ? Cela veut dire que le protocole, l’ensemble des règles que doivent suivre client (le BE) et serveur (le registre) sont formellement décrites dans un document développé et validé par une organisation de normalisation, en l’occurrence l’IETF (Internet Engineering Task Force). Pour EPP, le document en question est connu sous l’identité de « RFC 5730 ». Il est librement et gratuitement accessible mais sa lecture et sa compréhension nécessitent quelques efforts.
Il y a donc une communication, utilisant EPP au-dessus de l’Internet, entre le BE et le registre. Et une fois que le registre a reçu, mettons, une demande de création d’un nom ? Le logiciel du registre effectue diverses vérifications, puis inclut ce nom dans la base de données et voilà, un .fr de plus.
Notez bien que le processus est entièrement automatique. On voit parfois des gens s’étonner que tel ou tel nom de domaine ait été enregistré, et s’interroger « comment est-ce que l’Afnic a pu accepter ce nom ? », comme si un employé vérifiait chaque nom et décidait subjectivement de son intérêt ou des risques. Une telle vérification manuelle serait bien sûr trop lente, par rapport aux demandes des clients, et trop coûteuse, vu le prix d’un nom de domaine. Cela ne signifie pas que tout nom est acceptable, l’article 5.3 des règles d’enregistrement dans .fr précise « l’enregistrement et le renouvellement des noms de domaine s’effectuent sur la base des déclarations faites par le demandeur et sous sa responsabilité ». D’autres registres ont des règles similaires, rares sont ceux où le registre vérifie manuellement le nom avant son enregistrement.
Cela ne veut pas dire qu’il n’y a pas de tests du tout. Ainsi, le registre teste automatiquement la syntaxe du nom. Un nom de domaine comme « truc machin.fr » (avec un espace) sera refusé, pour des raisons syntaxiques complexes. De même, dans beaucoup de registres, il existe des listes de termes interdits ou dont l’enregistrement est soumis à des contraintes supplémentaires. Dans .fr, c’est par exemple le cas des termes soumis à un examen préalable, comme les noms de communes ou comme des termes liés au racisme, au nazisme, etc.
(Toujours pour parler de règles et d’interdictions, notez qu’il existe des procédures de résolution d’éventuels litiges au sujet des noms de domaine. Il y a la justice, bien sûr, mais aussi des procédures privées. Comme elles sont manuelles et non plus effectuées strictement par un logiciel, elles sont évidemment plus longues et coûteuses.)
Bon, désormais, le nom de domaine est dans la base de données. Plus personne d’autre ne peut l’enregistrer. (Si vous êtes le titulaire d’un nom, pensez quand même à sa sécurité, cf. le dossier thématique n° 9 de l’Afnic) Mais écrire dans la base du registre n’est qu’une partie des opérations, il faut aussi permettre au monde extérieur d’accéder aux informations de la base, ou en tout cas à une partie d’entre elles. C’est par exemple le rôle de deux autres protocoles, whois et RDAP (Registration Data Access Protocol) qui permettent de se renseigner sur un nom de domaine. Tous les deux rendent à peu près le même service, lire dans la base de données et formater le résultat pour l’envoyer au demandeur, la différence étant essentiellement technique. Whois est plus ancien (il a été normalisé dans le « RFC 3912 »), RDAP est l’avenir (sa norme est notamment faite des « RFC 7482 » et « RFC 7483 »). Contrairement au serveur EPP, les serveurs whois et RDAP sont la plupart du temps accessibles à tous et toutes, sans authentification. Dans les deux cas, le client est en mesure d’obtenir du serveur (le registre), une partie des informations. Je dis « une partie » car, en France, la loi Informatique & Libertés limite ce qu’on peut faire avec les données personnelles et une requête whois peut donc ne pas vous renvoyer toutes les informations dont le registre dispose, par exemple sur la personne titulaire d’un nom de domaine. Il ne s’agit pas d’anonymat (le registre connaît toujours la personne) mais de diffusion restreinte des informations au public. Outre whois et RDAP, la plupart des registres offrent également une interface Web d’interrogation de la base de données (souvent appelée « whois », par abus de langage).
Mais un autre moyen d’obtenir les informations stockées dans la base est sans doute plus important, c’est le DNS (Domain Name System). C’est même la motivation première pour les registres de noms de domaine. La personne ou organisation qui enregistre un nom ne le fait pas seulement pour stocker une information, comme c’est le cas par exemple avec les registres de marques. Cette organisation ou cette personne veut avant tout que son nom de domaine soit opérationnellement utile, qu’on puisse, par exemple, visiter le site Web qui utilise ce nom de domaine. C’est le rôle du DNS, un protocole crucial dans le fonctionnement de l’Internet. Il permet de récupérer très rapidement et efficacement des informations à partir d’un nom de domaine. Par exemple, c’est via le DNS qu’un navigateur Web qui veut aller visiter https://réussir-en.fr/ récupérera l’adresse IP associée au nom réussir-en.fr (aujourd’hui, c’est 2001:41d0:305:2100::6cfb). Pour que l’ensemble des serveurs DNS travaillent ensemble afin que ce navigateur Web obtienne l’information technique nécessaire pour se connecter au serveur Web, le registre doit déployer un ensemble de serveurs DNS faisant autorité. « Faisant autorité » signifie que ces serveurs connaissent la liste exacte des sous-domaines d’un domaine donné, et peuvent répondre avec certitude à toutes les requêtes concernant ce domaine. Ainsi, les serveurs faisant autorité pour .fr, gérés par l’Afnic, connaissent la liste de tous les noms sous .fr et peuvent donc répondre avec autorité « ce nom est géré par tel et tel serveur » ou bien « ce nom n’existe pas ». Pour qu’ils connaissent cette liste, toutes les dix minutes (dans le cas de .fr), un programme du registre extrait les changements de la base de données et les transmet aux serveurs faisant autorité.
La fiabilité de ces serveurs faisant autorité est cruciale. S’ils sont en panne, plus aucun nom sous le domaine qu’ils servent ne fonctionnera. C’est donc une des tâches essentielles du registre que de maintenir ces serveurs en fonctionnement 24 h sur 24, 365 jours par an, malgré les pannes matérielles, les coupures de réseau et les diverses attaques. Chaque serveur dont le nom est annoncé dans le DNS est ainsi composé de plusieurs machines physiques, placées à des endroits différents.
(Une parenthèse technique : tous les serveurs DNS ne sont pas des serveurs faisant autorité. Certains sont des résolveurs, qui ne connaissent aucun domaine par eux-même mais savent à qui demander. Ces résolveurs sont typiquement gérés par votre fournisseur d’accès à l’Internet ou par le service informatique de l’organisation où vous travaillez. Ces résolveurs ont une mémoire des questions récemment posées et des réponses correspondantes, et cette mémoire fait qu’ils transmettent parfois des informations légèrement datées. Tout changement au registre ne sera donc pas instantanément visible partout. Sur le fonctionnement du DNS, vous pouvez regarder la vidéo de l’Afnic.)
Le modèle présenté ici suppose un registre qui fait tout lui-même mais il y a parfois utilisation de divers niveaux de sous-traitance. Ainsi, certains registres sous-traitent une part des serveurs faisant autorité, par exemple pour assurer une diversité, gage de robustesse. C’est le cas de .fr (dans les noms des serveurs, ceux qui comprennent un « ext » sont extérieurs à l’Afnic, et une technique cryptographique, DNSSEC, permet de s’assurer qu’ils ne modifient pas les données). D’autres registres sous-traitent la totalité de l’hébergement DNS. Et certains sous-traitent également la gestion de la base de données, avec les services associés (comme EPP ou RDAP), gardant les responsabilités politiques, juridiques et commerciales.
Enfin, le registre a bien d’autres responsabilités. S’il se contentait de mettre des informations dans une base de données, cela ne serait pas grand’chose. Mais il assure de nombreuses autres missions, dont cet article ne présente qu’une partie. Terminons avec une de ces missions, qui est cruciale : la sauvegarde des données. Le matériel peut tomber en panne, faisant perdre des fichiers. Une attaque réussie peut mener également à la perte ou à l’indisponibilité de celles-ci. Le registre doit donc effectuer de fréquentes sauvegardes, vérifier celles-ci, les stocker de manière sécurisée, etc. (Certains registres, comme .fr, sont également soumis à une obligation de séquestre des données, qui consiste à confier périodiquement une copie à un organisme tiers, pour faire face à toute éventualité.)