Résumé

  • L’amorçage part d’adresses livrées avec le logiciel afin d’obtenir des données DNS actuelles. Cette configuration permet la première question ; elle ne constitue pas l’état final de la racine.
  • Une réponse NOERROR, avec AA et le RRset NS de la racine dans Answer, peut omettre des adresses dans Additional sans positionner TC. Une réponse d’amorçage n’est pas une referral et ces adresses ne sont pas la glue visée par RFC 9471.
  • Le résolveur doit produire les preuves manquantes : changer de cible après une absence de réponse, interroger directement les A et AAAA absents, remplir le cache, puis constater que les requêtes suivantes aboutissent.

Le silence le plus trompeur n’est pas une panne. C’est l’absence d’un signal que l’exploitant croyait obligatoire. Lors de l’amorçage DNS, des adresses de serveurs racine peuvent manquer à la section Additional, alors que le bit TC reste à zéro. Rien dans la réponse ne proclame : « cette liste est exhaustive ».

RFC 9609, publié en février 2025 comme BCP 209, décrit ce passage d’un résolveur récursif sans cache vers un état utilisable. Il remplace RFC 8109. Son apport le plus important n’est pas un nombre de serveurs ; c’est une discipline de preuve.

La configuration prête une première adresse

RFC 1034 décrivait déjà une structure de secours permettant à un résolveur vide de commencer. Aujourd’hui, le fournisseur du logiciel ou sa distribution livre généralement une liste d’adresses. Cette liste peut être exacte le jour de l’installation puis vieillir. Les identifiants des serveurs racine sont restés stables longtemps, tandis que leurs adresses peuvent changer.

L’amorçage n’accorde donc pas une autorité permanente au fichier initial. Il l’utilise pour poser une question actuelle au DNS : nom ., type NS, classe IN. Le bit RD devrait être nul. En UDP, l’aléa du port source recommandé par RFC 5452 et les cookies de RFC 7873 compliquent certaines réponses forgées. RFC 6891 permet d’annoncer une capacité EDNS utile.

Ces protections ne se remplacent pas. Un port imprévisible n’actualise pas les adresses. Un cookie n’atteste pas l’exhaustivité. Une grande taille EDNS n’oblige pas le serveur à envoyer tous les éléments souhaités. La vérité opérationnelle naît de leur enchaînement.

Un échec doit changer l’expérience

Si aucune réponse n’arrive, le résolveur doit essayer une autre adresse configurée. Répéter indéfiniment la même cible ne teste que l’obstination. La cible initiale devrait être choisie aléatoirement afin de répartir la charge et d’éviter que la première ligne du fichier ne devienne une dépendance de fait.

Après l’amorçage, la hiérarchie des preuves s’inverse. Lorsque le RRset NS reste en cache et qu’un préchargement est entrepris, le résolveur devrait employer les adresses du cache plutôt que revenir au souvenir potentiellement périmé de l’installation. La configuration perd ainsi le rôle qu’elle n’avait reçu que provisoirement.

Cette transition rejoint la logique de la spécification initiale minimale : fixer ce qui est nécessaire à l’interopérabilité de départ, puis laisser le logiciel en fonctionnement mesurer et choisir. RFC 9609 ne consacre aucune stratégie universelle de sélection après amorçage. Il cite des pratiques et maintient la décision au niveau local.

Une forme valide ne garantit pas tous les dépendants

La réponse attendue est précise : NOERROR, AA positionné, le RRset NS de la racine dans Answer, aucune donnée dans Authority. Les A et AAAA associés figurent dans Additional. Cette forme permet de rejeter une réponse mal construite.

Elle ne garantit pas que tous les enregistrements d’adresse sont présents. Le texte demande même de ne pas exiger exactement treize NS. Un identifiant n’est d’ailleurs ni un opérateur ni une instance physique. Le chiffre de plus de 1 500 instances donné lors de la publication est un repère historique, pas un compteur actuel ni un critère de validation.

Le résolveur doit traiter la réponse comme une donnée DNS normale injectée dans son cache. Les TTL expirent. Les RRsets se renouvellent. La racine ne reçoit pas un statut magique qui abolirait les règles ordinaires du cache.

Pourquoi TC peut rester silencieux

La matière A et AAAA combinée peut dépasser la place disponible. Dans une referral, RFC 9471 impose TC lorsqu’une contrainte de taille empêche d’inclure toute la glue nécessaire. Mais la réponse d’amorçage n’est pas une referral. Les adresses de serveurs racine présentes dans Additional ne sont pas de la glue au sens de cette obligation.

La conséquence est volontairement étroite : RFC 9609 n’exige aucun nombre d’adresses dans la réponse et n’exige pas TC pour signaler celles qui manquent. TC=0 signifie donc seulement que la règle du bit n’a pas été déclenchée. Il ne transforme pas la réponse en inventaire certifié.

On peut alors lire les preuves sans les mélanger :

  • NOERROR exclut une erreur DNS pour cette transaction ;
  • AA décrit l’autorité de la réponse ;
  • le RRset NS nomme les identifiants observés ;
  • une validation DNSSEC authentifie les données couvertes par sa chaîne ;
  • Additional fournit un sous-ensemble d’adresses ;
  • le cache conserve les données admises ;
  • seule une tentative ultérieure montre qu’une adresse est joignable depuis ce résolveur.

La bonne réparation change la question

Un serveur qui ordonne toujours ses enregistrements de la même façon peut reproduire la même omission à chaque répétition. Multiplier les mêmes requêtes ne produit alors aucune information nouvelle.

La réparation prescrite consiste à repérer les identifiants sans adresse puis à demander directement leurs RRsets A et AAAA. Le résolveur passe d’un espoir global—« peut-être que la prochaine réponse sera plus grande »—à une réconciliation par élément. C’est une méthode observable et testable.

Un tableau de bord sérieux doit donc séparer au moins la réception de la réponse, sa forme, le résultat DNSSEC, la couverture A/AAAA par identifiant, les requêtes complémentaires, l’admission au cache et les premières requêtes réussies après amorçage. Une seule coche verte détruit le chemin causal dont l’équipe aura besoin lors d’un redémarrage difficile.

Le RRset signé ne signe pas automatiquement les adresses

Lors de la publication de RFC 9609, le RRset NS de la racine était signé. Les adresses correspondantes se trouvaient sous root-servers.net, que le RFC décrit comme non signé à cette date. Cette précision temporelle est essentielle : le document rapporte un état de 2025, pas une promesse sur toutes les évolutions futures.

RFC 4033 explique ce que DNSSEC apporte et ce qu’il n’apporte pas. Une signature n’est ni une mesure de disponibilité ni une preuve de complétude. Un attaquant capable d’injecter une fausse réponse d’amorçage peut chercher à rediriger les requêtes vers un faux serveur racine. La validation détecte les falsifications lorsqu’une chaîne mène à des données signées ; elle ne protège pas par contagion toute donnée non signée.

Cette limite ne diminue pas DNSSEC. Elle empêche simplement d’agrandir sa garantie jusqu’à englober des faits qu’il ne signe pas.

La racine locale conserve les mêmes frontières

RFC 8806 permet d’exécuter une copie de la zone racine au voisinage du résolveur. RFC 9609 applique également l’amorçage à cette architecture. La distance diminue ; les catégories de preuve subsistent.

Un service local peut fonctionner avec une copie ancienne. Une zone valide peut être chargée tandis que le résolveur consulte une autre cible. Une réponse locale peut être correcte sans être complète pour le besoin de l’observateur. « Local » décrit la topologie, pas l’ensemble des propriétés du système.

Conserver la trace du passage

Pour un responsable, l’objet à gouverner n’est pas le paquet isolé mais le passage d’un état hérité vers un état observé. La trace devrait répondre à neuf questions : quelle révision de configuration a fourni les adresses ; quelle cible et quelle famille ont été choisies ; quels essais ont expiré ; la réponse respectait-elle la forme requise ; quel RRset et quel TTL ont été admis ; quelle validation a réussi ; quels identifiants manquaient d’A ou d’AAAA ; quelles requêtes directes ont fermé ces écarts ; quelles requêtes réelles ont ensuite abouti.

La primauté du code en fonctionnement prend ici un sens concret. Le RFC coordonne. Le logiciel déployé sélectionne, vérifie, met en cache et utilise. La conformité déclarée ne remplace pas cette série d’actes.

Le texte sur les couches de réalité aide à nommer l’erreur finale. Le fichier de démarrage n’est pas la racine. AA n’est pas l’exhaustivité. Un RRset NS n’est pas la joignabilité de tous ses membres. TC=0 n’est pas une déclaration qu’il ne manque rien. Et un standard publié n’est pas son déploiement.

Le système digne de confiance n’efface pas ces séparations. Il les franchit avec des preuves.