Qu’est-ce qu’un serveur racine ? Dé­fi­ni­tion et fonc­tion­ne­ment

Un serveur racine du DNS (ou sous sa forme abrégée : serveur racine) est un serveur qui joue un rôle fon­da­men­tal dans la tra­duc­tion d’un nom de domaine en une adresse IP. Il répond en effet aux demandes ou requêtes (Requests) des clients dans la zone racine du DNS (la zone racine marque le niveau le plus élevé, ou le premier niveau dans l’espace de nom du DNS). Les serveurs racine du DNS n’exécutent pas la ré­so­lu­tion de noms eux-mêmes, mais donnent plutôt aux clients les in­for­ma­tions sur les­quelles d’autres serveurs de noms (serveurs DNS) ob­tien­nent plus in­for­ma­tions sur l’adresse IP demandée.

Cela s’effectue via le fichier de zone racine qui fait partie de n’importe quel serveur racine du DNS. Le fichier en tant que tel n’a qu’une taille d’un peu moins de 2 Mo. Toutefois il contient tous les noms et toutes les adresses IP des domaines de premier niveau (ou TLD pour Top Level Domain). Ces données possèdent une fonction im­por­tante, en effet, un serveur racine s’appuie dessus quand il a appelé les serveurs DNS client, où d’autres in­for­ma­tions im­por­tantes con­cer­nant la requête sont dis­po­nibles.

Mais même si vous trans­fé­rez uni­que­ment les requêtes, les serveurs racine du DNS sont in­dis­pen­sables pour la ré­so­lu­tion de noms. Sans eux, le DNS ne fonc­tion­ne­rait pas sous sa forme actuelle. Un serveur racine travaille à la racine (root en anglais) du système de nom de domaine et est donc d’une certaine manière le plus important opérateur d’adresses Internet.

Mais comment un serveur racine du DNS aide à iden­ti­fier l’adresse IP d’un site Internet ? Pour com­prendre le fonc­tion­ne­ment du serveur racine, il est utile de retracer le dé­rou­le­ment principal de la ré­so­lu­tion de noms dans le DNS. En plus d’une adresse Internet in­di­vi­duelle (le nom de domaine), chaque service Internet possède une adresse IP numérique unique associée au nom de domaine. Par exemple le site Web de IONOS a reçu l’adresse IPv4 « 17.160.72.6 ». Si vous appelez dans votre na­vi­ga­teur www.ionos.fr, le nom al­pha­nu­mé­rique du site Web doit d’abord être converti en cette adresse IP afin que votre na­vi­ga­teur puisse afficher la page.

Le processus de ré­so­lu­tion de noms dans le DNS

L’objectif principal d’un DNS est la tra­duc­tion de noms de domaines en adresses IP (nommé également « forward lookup »). Le processus de ré­so­lu­tion de noms sur Internet est une opération hié­rar­chi­que­ment organisée. Mais avant que le DNS soit chargé de la ré­so­lu­tion de nom, le système essaie ha­bi­tuel­le­ment de trouver l’adresse IP souhaitée dans votre propre stockage de données.

Le nombre de stations dif­fé­rentes tra­ver­sées par une demande et dans quel ordre cela se produit dépendent bien évi­dem­ment d’autres facteurs comme le système d’ex­ploi­ta­tion utilisé ou si UDP (User Datagram Protocol) ou bien NetBIOS over TCP/IP est utilisé comme un protocole. Seule la ré­so­lu­tion de noms sur les dif­fé­rents serveurs dans le DNS est toujours la même. Nous allons vous expliquer les phases les plus im­por­tantes qui sont ef­fec­tuées lors de la recherche de l’adresse IP ap­pro­priée à un site Web et vous détailler quel rôle joue le serveur racine du DNS.

1. Après avoir initié un appel d’une page Web (comme par exemple www.ionos.fr) dans votre client, le « DNS Resolver local » de votre or­di­na­teur est assigné au départ à la ré­so­lu­tion de noms. Un « resolver » est un module qui agit comme une interface entre une ap­pli­ca­tion et un serveur DNS. Il regarde d’abord en premier dans le fichier hôte s’il existe une entrée pour le nom de domaine. À l’aide de ce fichier texte, la ré­so­lu­tion de nom peut être effectuée di­rec­te­ment via votre propre or­di­na­teur du moins si vous avez assigné ma­nuel­le­ment une adresse IP à un nom d’hôte au préalable. Comme le fichier hôte est un vestige de l’époque an­té­rieure à l’ap­pa­ri­tion des DNS et qu’il a été peu à peu remplacé par ce dernier, la plupart des uti­li­sa­teurs ne s’en sert pas et ne maintient pas le fichier, ce qui explique pourquoi il n’est gé­né­ra­le­ment pas une aide po­ten­tielle pour la ré­so­lu­tion de noms. 
2. S’il n’y a pas d’en­re­gis­tre­ment pour le site Web demandé dans le fichier hôte, l’ap­pli­ca­tion du « DNS-Resolver » ou le système d’ex­ploi­ta­tion vérifie désormais le cache (mémoire tampon) de votre client pour le nom de domaine. Si vous avez déjà visité la page Web demandée ou une autre page du même site sur Internet (par exemple « ionos.fr/di­gi­tal­guide/») et que les in­for­ma­tions à ce sujet se trouvent toujours dans le cache, alors l’adresse IP peut ainsi être acquise.
3. Si le « Resolver local » n’a pas pu effectuer la ré­so­lu­tion de noms dans le cache (parfois en raison de l’absence de cache), le DNS du réseau est utilisé par la suite. C’est ha­bi­tuel­le­ment votre routeur réseau à l’aide duquel vous allez sur Internet. Le DNS du routeur se renseigne sur le serveur de noms de votre four­nis­seur de services Internet (Provider) pour l’adresse IP du site Web dès lors qu’il ne l’a pas trouvé sur son propre cache.
4. Le serveur DNS de votre four­nis­seur tente de trouver l’adresse IP du nom de domaine en ef­fec­tuant un re­cou­pe­ment de sa base de données. Les dif­fé­rents « DNS-Resolvers » sont aussi utilisés pour obtenir les in­for­ma­tions.
5. Si ceci ne mène à aucun résultat, le serveur DNS du four­nis­seur se tournera alors vers un serveur racine et demandera d’autres in­for­ma­tions sur le domaine de premier niveau (TLD) du site Web demandé (la partie arrière d’un nom de domaine re­pré­sente le TLD, par exemple .com ou .fr). Le fichier de zone racine est consigné sur le serveur racine du DNS, il est chargé d’obtenir des in­for­ma­tions com­plé­men­taires sur un TLD en par­ti­cu­lier. Les in­for­ma­tions cor­res­pon­dantes à la demande sont par la suite trans­mises au serveur de noms du four­nis­seur. Dans le nom de domaine www.ionos.fr, le serveur racine s’adresse au serveur de noms TLD de l’Afnic (As­so­cia­tion française pour le nommage Internet en coo­pé­ra­tion), puisque ce dernier est res­pon­sable en tant qu’office d’en­re­gis­tre­ment de tous les noms de domaine .fr.
6. Ensuite le serveur de noms du four­nis­seur interroge le serveur de domaine de premier niveau (TLD) et ne reçoit pas encore de réponse dé­fi­ni­tive, mais la demande est à nouveau transmise : les serveurs de domaine de premier niveau n’ont qu’une fonction de transfert. Vous informez le serveur demandeur sur quel serveur DNS au­to­ri­taire le nom de domaine recherché est consigné.
7. A ce stade, le serveur du four­nis­seur se tourne désormais vers le serveur faisant autorité qui est res­pon­sable du nom de domaine et obtient fi­na­le­ment l’adresse IP désirée.
8. Enfin pour la dernière étape, le serveur du four­nis­seur transmet l’adresse IP au serveur DNS de votre routeur, qui le trans­met­tra à votre « Resolver local ». À partir de là, l’adresse est trans­fé­rée à votre na­vi­ga­teur, qui peut ainsi être utilisée pour demander, charger et afficher le site Internet.

Ainsi, pendant le processus de ré­so­lu­tion de nom, de nombreux serveurs dif­fé­rents peuvent être utilisés. Toutefois, dans le cadre de ce processus, les serveurs racine jouent un rôle spécial : ils re­pré­sen­tent l’instance suprême au sein de la ré­so­lu­tion de noms : si un nom de domaine ne peut pas être converti en adresse IP via le « Resolver local » ou le serveur DNS du four­nis­seur, un serveur racine est alors le premier point de contact pour la dé­ter­mi­na­tion de l’adresse IP. Et même si la ré­so­lu­tion de nom est réussie dans une étape pré­cé­dente, les in­for­ma­tions né­ces­saires stockées ont été col­lec­tées dans le passé par un serveur racine du DNS. Par con­sé­quent, il est important que les serveurs puissent cons­tam­ment assurer leur service.

Vue d’ensemble des serveurs racine du DNS

Il existe au total 13 prin­ci­paux serveurs de racine du DNS. Chacun est nommé à l’aide de lettres de « A » à « M ». Tous com­por­tent une adresse IPv4 et la plupart une adresse IPv6. La gestion de base du serveur racine est la res­pon­sa­bi­lité de l’ICANN (Internet Cor­po­ra­tion for Assigned Names and Numbers). Ils sont cependant gérés par des ins­ti­tu­tions dif­fé­rentes pour s’assurer que l’échange de données dans la zone racine est toujours correct, ac­ces­sible et sécurisé.  En plus des opé­ra­teurs des serveurs racine du DNS, la vue d’ensemble montre également les adresses IP.

Chaque serveur racine possède une copie identique du fichier de zone racine qui de temps en temps nécessite une mise à jour, par exemple si notamment le registre de nom de domaine qui est res­pon­sable d’un TLD change. La mo­di­fi­ca­tion apportée au fichier de la zone racine est un processus re­la­ti­ve­ment complexe : dès qu’une demande de mise à jour est effectuée, l’IANA (Internet Assigned Numbers Authority : un dé­par­te­ment de l’ICANN) la vérifie au préalable. Si tout est correct, alors le dé­par­te­ment du commerce américain doit approuver cette demande, car l’ICANN est con­trac­tuel­le­ment lié à cette autorité. Ce n’est qu’alors que la mo­di­fi­ca­tion sera mise en œuvre par la société Verisign (qui elle-même exploite deux serveurs racine) dans la zone racine.

Tous les jours, les serveurs racine sont con­fron­tés à un grand nombre de demandes. Cependant, la plupart des 13 serveurs de noms de la racine ne répondent pas uni­que­ment aux demandes des clients, mais le font en col­la­bo­ra­tion avec plusieurs autres serveurs : cette dis­tri­bu­tion des requêtes entrantes est contrôlée par la tech­no­lo­gie Anycast. Par con­sé­quent, il y a beaucoup plus que 13 serveurs qui prennent en charge les requêtes dans la zone racine. Au total plusieurs centaines de serveurs sont répartis à travers le monde. La plupart restent tout de même situés aux Etats-Unis et en Europe. La dis­per­sion des serveurs vise notamment à augmenter la ré­par­ti­tion de la charge et donc la fiabilité du serveur racine : avant l’uti­li­sa­tion d’Anycast il n y a avait que les 13 serveurs racine prin­ci­paux qui prenaient soins de répondre aux demandes. Puisque 10 d’entre eux se trouvent aux États-Unis, ce n’est que grâce à la tech­no­lo­gie Anycast qu’un trai­te­ment re­la­ti­ve­ment dé­cen­tra­lisé des demandes de la zone racine était sécurisé et garanti. La ré­par­ti­tion mondiale des serveurs favorise également des temps d’accès plus courts dans le trai­te­ment des demandes, car le serveur le plus proche s’occupe de répondre aux demandes. Une autre mesure de sécurité consiste à limiter la capacité du serveur racine utilisé en fonc­tion­ne­ment normal : en effet, seulement un tiers des res­sources in­for­ma­tiques totales dis­po­nibles est utilisé par les serveurs. Il s’agit de s’assurer que même malgré la dé­fail­lance de plusieurs serveurs racine du DNS, la ré­so­lu­tion de noms puisse rester stable. Dans ce cas, le serveur actif restant accepte les demandes qui étaient destinées aux serveurs dé­fail­lants en aug­men­tant sim­ple­ment son uti­li­sa­tion des res­sources. En con­sé­quence, dans le passé, diverses attaques DDoS sur le serveur racine du DNS n’ont pas eu beaucoup d’effets, puisque ces mesures de sécurité et pré­cau­tions sont bien trop puis­santes. Et les opé­ra­teurs des 13 serveurs racine con­nais­sent trop bien l’im­por­tance de ces serveurs pour le bon fonc­tion­ne­ment d’Internet : sans eux, l’adressage de tous les services Web est en péril.