Résumé

  • Le fichier de root hints ouvre un chemin de démarrage ; il ne constitue pas une autorité DNS durable.
  • RFC 9609 demande au résolveur d’interroger . pour le type NS, de mettre en cache la réponse racine comme une donnée DNS ordinaire et d’essayer une autre adresse configurée si la première ne répond pas.
  • La continuité repose sur une séparation nette : la configuration indique où commencer, tandis que la réponse faisant autorité fournit l’état actuel et périssable.

Analyse

Au premier démarrage, un cache vide crée un problème circulaire. Pour trouver un serveur de noms, il faudrait déjà savoir quel serveur interroger. Le fichier de root hints rompt ce cercle en donnant des adresses associées à certains identifiants de serveurs racine. Il ne livre pas la zone racine elle-même. Il fournit juste assez de portée pour poser la première question.

Cette question porte sur le nom racine ., avec le type NS et la classe Internet. RFC 9609 l’appelle requête d’amorçage. Envoyée à l’une des adresses configurées, elle doit permettre au résolveur d’obtenir l’ensemble courant des NS de la racine et les adresses disponibles qui leur correspondent. Une donnée issue de la distribution du logiciel cède alors la place à une donnée obtenue du DNS.

Le remplacement est essentiel. RFC 9609 décrit les adresses configurées comme des adresses présumées de certains serveurs racine. Elles sont généralement exactes lors de la distribution, mais peuvent vieillir. Les identifiants des serveurs racine sont restés stables depuis 1997 ; leurs adresses IPv4 ou IPv6, elles, peuvent changer. Utiliser uniquement le fichier statique exposerait le résolveur à des retards ou à des échecs évitables.

L’ancêtre du mécanisme apparaît dans RFC 1034. Son algorithme nommait SBELT la « ceinture de sécurité » utilisée quand le cache ne donnait plus aucun serveur pertinent. La configuration empêchait la résolution de tomber dans le vide. Elle n’avait pas vocation à conduire chaque requête ultérieure.

RFC 8109 a formalisé l’amorçage en 2017. RFC 9609 l’a remplacé en 2025 comme BCP 209. Le texte actuel précise le contenu des informations de départ, la prélecture avant expiration, la récupération d’adresses absentes et la nature exacte de la réponse. Les affirmations opérationnelles présentes doivent donc s’appuyer sur RFC 9609, RFC 8109 ne servant qu’à retracer l’évolution.

Le contrat de requête est volontairement borné. Le bit RD devrait être nul. EDNS0 devrait être utilisé, avec une capacité de réassemblage d’au moins 1024 octets. Sur UDP, le port source devrait être choisi aléatoirement ; les DNS Cookies peuvent compléter cette défense. Une corruption à ce stade aurait une portée considérable, puisque le point de départ influence toute la chaîne de résolution.

La réponse attendue doit porter NOERROR, activer le bit AA et placer l’ensemble NS de la racine dans la section Answer. La section Authority doit rester vide, puisque l’ensemble demandé figure déjà dans la réponse. La section Additional peut fournir les enregistrements A et AAAA des identifiants racine.

Ces adresses ne sont pas de la glue. Il ne s’agit pas d’un renvoi vers une zone enfant, mais d’une réponse directe concernant l’ensemble NS de la racine. RFC 9609 précise donc que la règle de troncature de RFC 9471 pour la glue de délégation ne s’applique pas. Une réponse peut omettre certaines adresses sans positionner TC.

Répéter exactement la même requête ne garantit pas davantage d’informations. Certains serveurs renvoient un ordre fixe et peuvent omettre les mêmes éléments. Le résolveur doit alors interroger directement les types A et AAAA pour les identifiants incomplets. Il ne doit pas non plus exiger treize NS dans chaque réponse, même si la photographie IANA gelée pour cet article contient treize identifiants.

Une fois mise en cache, la donnée racine suit le temps DNS ordinaire. L’ensemble NS expire selon son TTL. Le résolveur peut le précharger avant échéance ; dans ce cas, RFC 9609 recommande d’utiliser les adresses déjà apprises dans le cache plutôt que de revenir immédiatement à une configuration potentiellement ancienne. L’état actuel doit pouvoir renouveler l’état actuel.

Si une cible ne répond pas, le résolveur doit essayer une autre adresse configurée. La sélection devrait être aléatoire dans l’ensemble utilisable, compte tenu de la connectivité IPv4 ou IPv6 de l’hôte. La redondance du fichier a ainsi une fonction précise : offrir plusieurs sorties possibles depuis un cache vide, et non désigner un serveur privilégié.

Le fichier named.root d’IANA gelé ici se rattache à la version de zone racine 2026072901. Il présente treize identifiants, chacun avec une adresse A et une adresse AAAA, sous un TTL de 3 600 000 secondes. Ce comptage décrit le fichier, pas le monde physique. Chaque identifiant peut mener à de nombreuses instances anycast.

Le risque de sécurité reste réel. Une fausse réponse d’amorçage peut rediriger le trafic futur du résolveur. RFC 9609 indique qu’aucune prévention définitive n’existe tant que ces réponses ne sont pas protégées par DNSSEC. La validation ultérieure peut révéler certaines attaques, mais elle ne transforme ni le fichier de hints ni l’adresse de départ en preuve d’identité.

Après l’amorçage, le logiciel choisit encore comment sélectionner ses serveurs : mesure du plus rapide, groupes de performance ou tirage aléatoire. Le BCP n’impose pas un algorithme unique et recommande de ne pas rendre la racine exceptionnellement mystérieuse. L’ensemble NS racine reste une donnée DNS, avec ses délais, son accessibilité et son expiration.

La réussite historique du mécanisme tient à cette modestie. La configuration permet de demander. L’autorité répond. Le TTL retire à la réponse son caractère actuel. La politique de reprise empêche une adresse morte de devenir une panne générale. Un indice de démarrage devient fiable lorsqu’un système sait précisément quand le remplacer.

Sources