Accueil / Nommage
Treize identités, douze organisations, aucune autorité unique
Les serveurs racines sont le point de départ de toute résolution de nom. Ils ne détiennent presque rien : une liste d'extensions et les serveurs qui en ont la charge. Leur nombre est plafonné par un héritage technique vieux de trente ans, et leur robustesse vient d'une astuce de routage.
Qui opère les treize racines
Sélectionnez une lettre pour voir son opérateur. Les flèches du clavier fonctionnent aussi.
Pourquoi cette diversité compte
Une entreprise cotée, deux universités, une agence spatiale civile, deux organisations militaires, trois associations à but non lucratif, un opérateur de transit, un registre régional européen et un consortium de recherche japonais. Cette composition n'a pas été planifiée : elle résulte de l'histoire. Mais elle produit un effet précis — aucune décision unique, qu'elle soit judiciaire, commerciale ou politique, ne peut atteindre les treize à la fois.
Pourquoi exactement treize
La réponse tient dans une contrainte de taille de paquet. Quand un résolveur démarre, il demande à un serveur racine la liste officielle des serveurs racines — une opération appelée amorçage. Cette réponse devait tenir dans un seul paquet UDP non fragmenté, soit 512 octets selon le RFC 1035.
À la fin des années 1990, les serveurs racines faisaient aussi autorité pour .com, .net et .org. Le calcul de l'époque, documenté par le comité consultatif RSSAC : l'en-tête et les enregistrements occupaient 435 octets, il restait 77 octets pour la question posée, dont 64 étaient jugés nécessaires. Ajouter un quatorzième serveur coûtait 25 octets de plus. 435 + 64 + 25 dépasse 512. On s'est arrêté à treize.
Cette limite n'existe plus. Le mécanisme EDNS(0), normalisé par le RFC 6891, permet depuis longtemps des réponses bien plus grandes, et l'ajout des adresses IPv6 a de toute façon fait dépasser les 512 octets. Mais le nombre est resté, pour une raison simple : l'anycast a rendu l'ajout d'identités inutile.
L'anycast, ou comment treize devient deux mille
L'anycast consiste à annoncer la même adresse IP depuis des centaines d'endroits différents. Le routage mondial se charge du reste : chaque requête part vers l'instance la plus proche au sens du réseau. Un résolveur bruxellois qui interroge k.root-servers.net parle à une machine européenne ; un résolveur chilien parle à une autre machine, avec la même adresse.
Trois conséquences pour la sécurité :
- Latence. Une requête vers une racine se règle typiquement en moins de dix millisecondes, parce que l'instance est souvent dans le même pays, voire dans le même point d'échange.
- Absorption des attaques. Un déni de service distribué se répartit mécaniquement sur les instances proches de ses sources. Il n'existe pas de cible unique à saturer.
- Confinement des pannes. Si une instance tombe, le routage la retire et les requêtes basculent vers la suivante, sans intervention humaine et sans changement de configuration chez personne.
L'Internet Systems Consortium a été le premier opérateur racine à déployer l'anycast, en 2002, juste après l'attaque d'octobre. Les autres ont suivi. On est passé d'une centaine d'instances au milieu des années 2000 à plus de deux mille aujourd'hui, réparties sur tous les continents habités.
Ce que l'anycast ne protège pas
L'anycast dépend entièrement du routage BGP. Une annonce illégitime de l'un des préfixes racines détournerait les requêtes vers un serveur contrôlé par un tiers. C'est déjà arrivé pour d'autres services critiques. La parade n'est pas dans le DNS mais dans le routage — voir la page consacrée à la RPKI — et dans DNSSEC, qui rend une fausse réponse détectable même si elle vient de la bonne adresse.
La zone racine elle-même
Ce qu'elle contient
La zone racine est un fichier texte d'environ deux mégaoctets. Elle liste les quelque 1 600 extensions de premier niveau existantes — .com, .be, .fr, .museum, les extensions en caractères non latins — et, pour chacune, les serveurs qui en ont la charge, plus les enregistrements DS qui amorcent la chaîne DNSSEC.
Elle ne contient aucun nom de domaine ordinaire. L'ensemble des enregistrements de .com seul pèserait des centaines de gigaoctets.
Qui la fabrique
Trois rôles distincts, délibérément séparés :
- L'IANA, opérée par PTI, filiale de l'ICANN, tient le registre et instruit les demandes de modification des opérateurs d'extensions.
- Verisign, en tant que mainteneur de la zone racine, génère le fichier, le signe avec la clé de zone et le distribue.
- Les douze opérateurs racines le chargent et le servent, chacun selon sa propre infrastructure.
Aucun des trois ne peut agir seul. Une modification frauduleuse exigerait une collusion, et serait immédiatement visible : la zone est publique et comparable par n'importe qui.
Transparence par défaut
La zone racine complète est publiquement téléchargeable. Les journaux d'audit des cérémonies de clé, les vidéos de ces cérémonies et les rapports d'audit indépendants le sont également. La sécurité du système ne repose pas sur le secret des procédures, mais sur le fait que n'importe qui peut les vérifier.
Ce qui se passe quand on l'attaque
Le système racine a été attaqué frontalement au moins deux fois, et n'a jamais cessé de fonctionner.
Octobre 2002
Une attaque coordonnée vise les treize identités. Plusieurs sont dégradées pendant environ une heure. Aucun utilisateur ne s'en aperçoit, principalement parce que les résolveurs conservent les réponses racines en cache pendant des jours. L'épisode déclenche le déploiement généralisé de l'anycast.
Novembre 2015
Deux vagues d'attaque envoient jusqu'à cinq millions de requêtes par seconde et par serveur. La plupart des opérateurs continuent de répondre aux requêtes légitimes. C'est la démonstration en conditions réelles que la charge se répartit au lieu de se concentrer.
Pourquoi ça tient
- Répartition. Le trafic d'attaque est absorbé près de ses sources, sur des centaines d'instances distinctes.
- Cache. Les résolveurs du monde entier gardent les délégations racines en mémoire, souvent 48 heures. Une indisponibilité brève reste invisible.
- Surdimensionnement. Les opérateurs provisionnent bien au-delà de la charge normale, précisément pour cette raison.
- Hétérogénéité. Systèmes d'exploitation, logiciels DNS et fournisseurs de transit diffèrent d'un opérateur à l'autre. Une faille unique ne peut pas tous les atteindre.
Servir la racine chez soi
Le RFC 8806 décrit une technique parfois mal comprise : un opérateur peut charger une copie locale de la zone racine directement dans son résolveur. Le résolveur répond alors lui-même aux requêtes portant sur les extensions, sans jamais sortir sur le réseau.
Cela n'a rien d'une racine alternative. La zone provient des sources officielles, elle est vérifiée par DNSSEC, et son contenu est identique. Les bénéfices sont opérationnels :
- Réduction de la latence sur les premières requêtes, notamment dans les régions mal connectées.
- Moins de fuite d'information : les serveurs racines ne voient plus les requêtes portant sur des noms inexistants.
- Continuité si la connectivité internationale est coupée : la résolution interne continue de fonctionner.
La contrepartie est une charge d'exploitation supplémentaire — il faut surveiller la fraîcheur de la copie. La plupart des grands résolveurs publics utilisent une variante de cette approche.
À ne pas confondre avec les racines alternatives
Il existe des systèmes qui publient leur propre zone racine avec des extensions non reconnues. Ils ne sont pas illégaux, mais ils produisent un espace de noms différent : le même nom peut y désigner autre chose qu'ailleurs. C'est exactement ce que l'unicité de la racine officielle est censée empêcher. Le fait que exemple.be désigne la même chose depuis Bruxelles, Lagos ou Séoul est une propriété, pas un hasard.