Serveur DNS racine : à quoi il sert et comment l’interroger

Un serveur DNS racine fait autorité sur la zone « . », le sommet de l'arborescence DNS, et ne sait faire qu'une chose : indiquer quels serveurs interroger pour une extension donnée (.fr, .com, .org). Il existe 13 identités nommées de a.root-servers.net à m.root-servers.net, exploitées par 12 organisations et répliquées par anycast sur plus de 1 500 machines réparties dans le monde.

Sommaire

Un serveur racine ne connaît presque rien

Lancez `dig @a.root-servers.net www.adresse-ip.fr +norecurse` : vous n'obtiendrez aucune adresse IP. La réponse revient avec `ANSWER: 0`, sans le flag `aa`, et une section AUTHORITY qui liste d.nic.fr, e.ext.nic.fr, f.ext.nic.fr et g.ext.nic.fr, les serveurs de l'Afnic pour .fr. Voilà l'intégralité de ce que sait la racine : à qui passer la main pour chaque extension.

La zone racine est minuscule au regard de ce qu'elle porte. Elle contient environ 1 500 délégations de TLD (le décompte exact est publié dans la base de la zone racine de l'IANA), et le fichier complet se télécharge en clair sur internic.net/domain/root.zone. Aucun enregistrement A de site web n'y figure.

Un serveur racine n'intervient donc qu'une fois par chaîne de résolution, et encore : seulement quand le résolveur n'a plus en cache la liste des serveurs de l'extension visée. Sur un résolveur qui tourne depuis quelques heures, la racine n'est presque plus sollicitée.

Les enregistrements NS de chaque TLD, avec un TTL de 172800 secondes (2 jours)
Les enregistrements de glue A et AAAA de ces serveurs de TLD
Les enregistrements DS qui portent l'empreinte de la clé DNSSEC de chaque extension
Le NS et le SOA de la zone « . » elle-même, dont le MNAME est a.root-servers.net et le TTL 518400 secondes (6 jours)

13 identités, 12 opérateurs, des milliers de machines

Le chiffre 13 n'a rien de mystique : il vient de la limite de 512 octets fixée pour un message DNS sur UDP par la RFC 1035. Treize serveurs avec leurs adresses IPv4 tenaient dans cette enveloppe, quatorze non. Depuis EDNS0 (RFC 6891) la contrainte a sauté, mais les 13 identités sont restées, et la réponse de priming complète avec IPv6 dépasse aujourd'hui les 800 octets : un résolveur qui n'annonce pas EDNS0 reçoit une réponse tronquée (flag TC) et doit basculer en TCP.

Ces 13 noms sont exploités par 12 organisations distinctes, Verisign gérant A et J. Aucune n'a de pouvoir sur le contenu de la zone : celui-ci est décidé par l'IANA/PTI et publié par Verisign en tant que Root Zone Maintainer. Les opérateurs ne font que servir le fichier.

Identité	Opérateur	IPv4	IPv6
a.root-servers.net	Verisign	198.41.0.4	2001:503:ba3e::2:30
b.root-servers.net	USC-ISI	170.247.170.2	2801:1b8:10::b
c.root-servers.net	Cogent Communications	192.33.4.12	2001:500:2::c
d.root-servers.net	University of Maryland	199.7.91.13	2001:500:2d::d
e.root-servers.net	NASA Ames Research Center	192.203.230.10	2001:500:a8::e
f.root-servers.net	Internet Systems Consortium	192.5.5.241	2001:500:2f::f
g.root-servers.net	US DoD (DISA)	192.112.36.4	2001:500:12::d0d
h.root-servers.net	US Army Research Lab	198.97.190.53	2001:500:1::53
i.root-servers.net	Netnod (Suède)	192.36.148.17	2001:7fe::53
j.root-servers.net	Verisign	192.58.128.30	2001:503:c27::2:30
k.root-servers.net	RIPE NCC	193.0.14.129	2001:7fd::1
l.root-servers.net	ICANN	199.7.83.42	2001:500:9f::42
m.root-servers.net	WIDE Project (Japon)	202.12.27.33	2001:dc3::35

Anycast : 13 adresses, plus de 1 500 machines

Chacune de ces 13 adresses est annoncée en BGP depuis des dizaines de sites simultanément. Votre paquet part vers 193.0.14.129 et atterrit sur l'instance K la plus proche au sens du routage, souvent dans votre pays ou chez votre opérateur de transit. Le compteur en direct des instances est publié sur root-servers.org.

Vous pouvez identifier l'instance qui vous répond. La commande `dig +short CHAOS TXT id.server @k.root-servers.net` renvoie un identifiant de site (la RFC 4892 définit ce mécanisme) ; sur les serveurs plus anciens, `hostname.bind` fait le même travail. Testez la même commande depuis deux réseaux différents : vous n'obtiendrez pas la même valeur.

Cette architecture explique pourquoi la latence vers une racine se compte en millisecondes presque partout, et pourquoi un déni de service localisé ne fait tomber que quelques instances sur des centaines.

Le priming : comment un résolveur trouve la racine

Un résolveur qui démarre à froid ne connaît rien. Il embarque un fichier d'amorçage, le root hints (nommé `named.root` ou `root.hints`, distribué sur internic.net/domain/named.root), qui contient les 13 noms et leurs adresses. Dans BIND, cela s'écrit `zone "." { type hint; file "named.root"; };`. Unbound et systemd-resolved embarquent la liste en dur dans le binaire.

Ce fichier ne sert qu'une fois. Le résolveur envoie une requête `. NS` à l'une des 13 adresses, récupère le jeu NS faisant autorité avec ses glue records, et travaille ensuite sur cette réponse et non sur le fichier local. C'est la requête de priming, décrite par la RFC 8109. Le TTL de 518400 secondes fait que l'opération se répète environ une fois par semaine.

Conséquence pratique : un fichier hints périmé n'empêche pas le service tant qu'au moins une adresse sur les treize répond. En novembre 2023, b.root-servers.net est passé de 199.9.14.201 à 170.247.170.2 sans que personne ne s'en aperçoive, l'ancienne adresse restant servie en parallèle. Mettez quand même le fichier à jour une fois par an.

Pour observer la chaîne complète depuis la racine, `dig +trace adresse-ip.fr` affiche chaque saut, du serveur racine au serveur de .fr puis au serveur faisant autorité sur le domaine.

DNSSEC : la racine est le point d’ancrage de la confiance

La zone racine est signée depuis le 15 juillet 2010. Sa clé de signature de clés, la KSK, est le trust anchor à partir duquel toute validation DNSSEC remonte : le résolveur vérifie la signature de la racine, y trouve le DS de .fr, valide la clé de .fr, y trouve le DS du domaine, et ainsi de suite jusqu'à l'enregistrement demandé.

La KSK actuelle, dite KSK-2017, a remplacé KSK-2010 le 11 octobre 2018, lors du premier changement de clé racine de l'histoire du DNS. Cette opération a été préparée pendant des années précisément parce qu'un résolveur resté sur l'ancienne clé aurait cessé de valider, donc de répondre, sur l'ensemble des zones signées. La RFC 5011 décrit le mécanisme de mise à jour automatique du trust anchor qui a permis d'absorber ce changement.

En pratique, `dnssec-validation auto;` dans BIND ou `auto-trust-anchor-file: "root.key"` dans Unbound suffisent : la clé est embarquée puis mise à jour toute seule. La référence officielle reste le fichier root-anchors.xml publié sur data.iana.org/root-anchors/. Vérifiez ce que voit votre résolveur avec `dig . DNSKEY +dnssec`.

Ce qu’on confond souvent avec un serveur racine

Le résolveur que vous configurez dans votre box ou votre `/etc/resolv.conf` n'est pas un serveur racine. 8.8.8.8, 9.9.9.9 ou 1.1.1.1 sont des résolveurs récursifs : ils interrogent la racine pour votre compte, mettent les réponses en cache et vous renvoient le résultat final. Un serveur racine, lui, ne fait jamais de récursion et refuse poliment de résoudre quoi que ce soit.

Autre confusion fréquente : « serveur racine » et « serveur de TLD ». Les machines de l'Afnic qui font autorité sur .fr ne sont pas des racines, elles sont un cran en dessous. La racine se contente de dire où les trouver.

Enfin, « 13 serveurs racine » ne veut pas dire 13 machines. Il y a 13 identités DNS, 13 couples d'adresses IP, et plusieurs centaines de sites physiques derrière. Le vocabulaire précis parle d'identités et d'instances.

Côté vie privée, un serveur racine ne voit pas votre trafic : c'est votre résolveur qui l'interroge, avec sa propre adresse IP. Et depuis la généralisation de la minimisation du nom de requête (RFC 9156), le résolveur n'envoie à la racine que le TLD demandé, pas le nom complet.

Que se passe-t-il si la racine est attaquée

Les racines ont été visées à plusieurs reprises, notamment le 21 octobre 2002, où neuf des treize identités ont été dégradées, et le 6 février 2007, où G et L ont encaissé l'essentiel du trafic. Dans les deux cas, l'effet sur les utilisateurs est resté marginal, pour deux raisons : l'anycast dilue la charge, et les caches des résolveurs tiennent plusieurs jours grâce au TTL de six jours du jeu NS racine.

Le volume exact de requêtes reçues chaque jour ne se résume pas à un chiffre unique : chaque opérateur publie ses propres statistiques via root-servers.org. Une part notable de ce trafic concerne des extensions qui n'existent pas et repart en NXDOMAIN, effet secondaire de suffixes internes mal configurés et de logiciels bavards.

Si vous exploitez un résolveur à fort volume, la RFC 8806 décrit une option intéressante : maintenir une copie locale de la zone racine, transférée par AXFR depuis un serveur qui l'autorise. Dans Unbound cela se configure avec un bloc `auth-zone: name: "."` et `fallback-enabled: yes` ; dans BIND 9.14 et suivants avec `zone "." { type mirror; };`. La latence du premier saut tombe à zéro et plus aucune requête de votre parc ne part vers l'extérieur pour un TLD inexistant.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Que renvoie un serveur DNS racine interrogé pour www.exemple.fr ?

Questions fréquentes

Combien y a-t-il de serveurs racine dans le monde ?

13 identités DNS (a à m.root-servers.net), mais plus de 1 500 machines physiques réparties sur tous les continents grâce à l'anycast. Le décompte à jour, site par site, est publié sur root-servers.org. Dire « il n'y a que 13 serveurs racine » est exact au niveau des noms et faux au niveau du matériel.

Pourquoi exactement 13 serveurs racine ?

La RFC 1035 limitait un message DNS transporté sur UDP à 512 octets. La réponse de priming, qui liste les serveurs racine avec leurs adresses IPv4, tenait dans cette taille avec 13 entrées, pas 14. EDNS0 (RFC 6891) a levé cette limite depuis longtemps, mais changer le nombre imposerait de mettre à jour tous les fichiers d'amorçage de la planète pour un gain nul, l'anycast répondant déjà au besoin de capacité.

Peut-on interroger un serveur racine soi-même ?

Oui, ils sont publics et répondent à tout le monde. `dig . NS @198.41.0.4` renvoie la liste des treize. `dig @a.root-servers.net com. NS +norecurse` renvoie la délégation vers les serveurs de .com. En revanche, `dig @a.root-servers.net www.google.com` ne donnera pas d'adresse IP : le serveur ne fait pas de récursion et vous renvoie simplement vers les serveurs de .com.

Faut-il mettre à jour le fichier root.hints de son résolveur ?

Une fois par an suffit. Les adresses changent rarement : la dernière modification notable date de novembre 2023, quand b.root-servers.net est passé en 170.247.170.2. Comme le résolveur ne se sert du fichier que pour son premier contact, il continue de fonctionner tant qu'une adresse sur treize reste valide. Téléchargez la version courante sur internic.net/domain/named.root.

Les serveurs racine peuvent-ils voir les sites que je visite ?

Non. C'est votre résolveur récursif qui les interroge, avec sa propre adresse IP source ; la vôtre n'apparaît jamais. Et avec la minimisation du nom de requête normalisée par la RFC 9156, le résolveur n'envoie à la racine que l'extension concernée, par exemple « fr. », et non le nom d'hôte complet. Votre résolveur, lui, voit tout.

Que se passerait-il si tous les serveurs racine tombaient en même temps ?

Rien d'immédiat. Les résolveurs gardent le jeu NS racine en cache pendant 518400 secondes, soit six jours, et les délégations de TLD pendant 172800 secondes, soit deux jours. La résolution des domaines déjà consultés continuerait ; les problèmes commenceraient à apparaître au bout de quelques jours, à mesure que les caches expirent et que les nouvelles délégations deviennent introuvables.