Pourquoi n'y a-t-il que 13 groupes de serveurs racines dans le monde ?

1. La contrainte stricte du protocole : 512 octets

1.1 MTU IPv4 et UDP sans fragmentation

Les premiers réseaux ARPANET / IPv4 imposaient une MTU minimale de 576 octets. Chaque hôte devait pouvoir recevoir des paquets de cette taille, faute de quoi même l'accessibilité de base n'était pas garantie (RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• Longueur totale de 576 octets − en-tête IP typique de 20 octets − en-tête UDP de 8 octets ≈ 548 octets utilisables (avec des options, l'en-tête IP peut atteindre 60 octets, ce qui en laisse moins)
• La RFC 1035 § 4.2.1 a retenu la puissance de deux plus prudente, 512 octets, comme plafond strict du DNS sur UDP — une valeur sûre même lorsque l'en-tête IP porte toutes ses options
• Si une réponse UDP dépasse 512 octets, elle doit être tronquée avec le bit TC positionné, ce qui oblige le client à se rabattre sur TCP — et la poignée de main TCP en trois temps multiplie la latence de la première résolution

Autrement dit, « la liste complète des serveurs racines doit tenir dans un seul paquet UDP de 512 octets » — sinon, chaque requête vers la racine dans le monde aurait dû passer par TCP, ce qui aurait été quasi catastrophique sur le matériel des années 1980.

1.2 Structure en octets du message DNS

Structure complète de la réponse à une requête des enregistrements NS de . (le serveur renvoie tous les enregistrements NS racines ainsi que les enregistrements glue A) :

Header   (12 octets)

Formule de la longueur totale :

En appliquant la limite de 512 octets :

En théorie, cela permet jusqu'à 15 groupes, mais il faut garder de la marge pour les signatures DNSSEC, le pseudo-enregistrement OPT d'EDNS0 et le remplissage des champs : le nombre s'est donc fixé à 13 groupes. La RFC 2010 (1996) a défini les critères d'exploitation des serveurs racines, et leur nombre n'a plus changé depuis la mise en service de M-root l'année suivante.

1.3 Testez vous-même — <code>dig +noedns -t ns .</code> renvoie environ 490 à 510 octets

Voilà pour la théorie. Interrogeons maintenant un serveur racine avec dig pour voir la taille réelle de la réponse :

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (13 enregistrements NS au total, c–l omis)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (les 13 enregistrements glue A tiennent tous)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ seuls 2 enregistrements AAAA tiennent — le paquet est plein

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

La ligne clé se trouve à la fin — une réponse totale d'environ 490 à 510 octets, nettement sous les 512 (le chiffre exact dépend du serveur racine interrogé et du nombre d'enregistrements glue IPv6 renvoyés) — ce qui correspond au budget d'octets ci-dessus. Notez l'option +noedns : par défaut, dig envoie EDNS0 et la réponse dépasse alors largement 800 octets. C'est précisément pour cela que les 512 octets ont cessé d'être une limite stricte une fois EDNS0 généralisé — mais le chiffre 13 était déjà figé à ce moment-là.

2. D'où vient le chiffre 13 ? Un bref historique

Ce nombre n'a pas été fixé dès le départ. Le nombre de serveurs racines a connu plusieurs extensions ; après la mise en service de M-root (WIDE, Japon) en 1997, il n'a plus jamais changé :

Une fois le nombre fixé à 13, les noms en lettres de A à M ne changent plus jamais : seul le matériel est mis à niveau et de nouveaux miroirs anycast sont ajoutés. Le fichier root hints d'Internet (named.root) est depuis longtemps intégré au code de milliards de résolveurs récursifs et de clients stub ; changer un seul chiffre reviendrait à mettre à jour tout Internet.

3. Mais n'y a-t-il vraiment que 13 machines dans le monde ?

Non. C'est l'idée reçue la plus répandue. « 13 groupes de serveurs racines » désigne 13 noms NS (a–m.root-servers.net), chacun associé à une adresse IPv4 et à une adresse IPv6 — et non 13 machines physiques.

Derrière chaque IP se trouve un cluster anycast : la même adresse IP est annoncée simultanément via BGP par des centaines de datacenters dans le monde, et la requête DNS d'un utilisateur est acheminée vers le miroir le plus proche en RTT. Quand un serveur racine « tombe », il s'agit généralement d'un miroir en maintenance dans une ville donnée — la résolution mondiale n'est pas affectée.

État des 13 groupes de serveurs racines en 2024

La Chine continentale (Pékin, Shanghai, Shenzhen, Guangzhou, Hefei, etc.) héberge des nœuds miroirs anycast de plusieurs serveurs racines, dont F / I / J / K / L ; depuis la Chine, le RTT mesuré vers les serveurs racines est généralement inférieur à 20 ms.

4. Depuis EDNS0, la limite de 512 octets n'en est plus vraiment une

On peut se demander : les paquets DNS de 4 Ko ou plus sont courants aujourd'hui, alors pourquoi ne pas simplement « dépasser 13 » ?

• EDNS0 (RFC 2671 en 1999, aujourd'hui RFC 6891) — négocie une charge utile UDP plus grande (souvent 4096 octets) et est pris en charge par tous les résolveurs modernes
• DNSSEC impose EDNS0, car les données de signature dépassent à elles seules largement 512 octets
• Repli sur TCP — la poignée de main TCP en trois temps, plus TLS / cookies, ne coûte plus grand-chose aujourd'hui

Mais la liste des serveurs racines fait désormais l'objet d'un consensus à l'échelle du réseau : chaque résolveur récursif de la planète code en dur ces 13 groupes dans son fichier root hints (named.root), et derrière ces résolveurs se trouvent des milliards de terminaux. Aucun intérêt à changer, et un risque de fracturer l'Internet mondial : ce nombre restera donc très probablement 13 pour toujours.

En résumé : « 13 groupes » est physiquement dépassé depuis longtemps, mais impossible à remettre en cause sur le plan technique.

5. Points clés

1. Raison historique : la limite de 512 octets du DNS sur UDP → un plafond mathématique de 15 groupes → 13 retenus avec de la marge, figés depuis la mise en service de M-root en 1997
2. Inertie du protocole : mettre à jour les fichiers root hints de milliards de terminaux est irréaliste, donc rien ne change
3. Capacité réelle : plus de 1395 nœuds miroirs anycast, ce qui rend le risque de point de défaillance unique quasi nul
4. Accessibles depuis la Chine : plusieurs serveurs racines, dont F / I / J / K / L, disposent de miroirs en Chine continentale, avec un RTT mesuré < 20 ms