Résumé

  • Les copies parent et enfant d'une délégation peuvent porter des TTL différents. Réduire le TTL chez l'enfant ne raccourcit pas une entrée déjà mise en cache depuis le parent.
  • RFC 9199 rapporte qu'environ 90 % des résolveurs observés suivaient la durée de l'enfant et près de 10 % celle du parent. Le traitement des adresses varie aussi selon qu'un serveur se trouve ou non dans le bailiwick.
  • L'ancienne infrastructure doit rester disponible au moins pendant le plus long des deux TTL. La décision finale doit encore tenir compte du dernier remplissage possible, des TTL A/AAAA et des observations de plusieurs familles de résolveurs.

Deux publications exactes, deux échéances incompatibles

Dans une délégation DNS, la même direction est donnée à deux endroits. Le parent publie les enregistrements NS qui permettent de trouver la zone enfant. Une fois arrivée, la résolution obtient auprès de l'enfant sa propre version des NS. Les noms devraient coïncider. Les durées de cache, elles, peuvent diverger.

Cette différence ne signale pas forcément une faute. Elle reflète deux autorités distinctes. L'opérateur de l'enfant choisit la valeur servie par sa zone, mais il ne maîtrise souvent pas la valeur de fait imposée par le parent. RFC 9199 cite ainsi le cas des NS de TLD dans la racine, dotés d'un TTL de deux jours, alors qu'un TLD peut annoncer une durée bien plus courte de son côté.

L'étude de Giovane Moura, Wes Hardaker, John Heidemann et Marco Davids a observé la conséquence sur des résolveurs réels. Dans l'échantillon résumé par RFC 9199, environ neuf résolveurs sur dix paraissaient « centrés enfant » ; un sur dix conservait la logique du parent. Il ne faut pas transformer ce résultat daté en loi universelle. Il suffit toutefois à invalider une pratique : juger une migration sur la majorité visible.

Si l'ancien serveur est arrêté à l'échéance courte, la minorité qui détient encore une copie parent valide reçoit une délégation vers une infrastructure disparue. L'incident paraît intermittent, lié à certains réseaux ou territoires, alors que sa cause est déterministe : deux caches ont respecté deux instructions valides.

Un TTL nouveau ne remonte pas le temps

Le TTL n'est pas une télécommande. Il accompagne une donnée au moment où le résolveur la met en cache. Le DNS ne prévoit pas de commande permettant à une zone de rappeler à distance toutes les copies déjà stockées. Une valeur réduite règle les futurs remplissages ; elle ne modifie pas la durée restante d'une entrée ancienne.

Préparer une migration en abaissant les TTL reste une bonne méthode, à condition de respecter l'ordre des événements. La petite valeur doit être publiée assez tôt pour que la dernière copie remplie sous l'ancienne grande valeur ait expiré avant la bascule. Et l'opération doit couvrir chaque surface contrôlée séparément. Une heure chez l'enfant n'annule pas quarante-huit heures chez le parent.

D'où la formulation prudente de RFC 9199 : conserver l'ancienne infrastructure en état de marche pendant au moins le maximum des TTL parent et enfant. Ce maximum n'est pas un certificat automatique. C'est le plancher à partir duquel il devient raisonnable d'examiner le dernier remplissage, le délai de publication du parent et les caches d'adresses.

Les longs TTL ont leur utilité : réponses plus rapides depuis le cache, moins de charge sur les serveurs faisant autorité, coûts plus faibles et meilleure tenue face à une courte panne ou attaque. Les petits TTL offrent de l'agilité. Le choix relève d'un compromis. L'erreur consiste à attribuer à l'enfant le pouvoir de supprimer le compromis choisi par le parent.

L'adresse du serveur possède sa propre mémoire

Un NS fournit un nom, pas toujours l'adresse nécessaire pour joindre le serveur. Les enregistrements A et AAAA introduisent donc une autre échéance.

Quand le serveur est dans le bailiwick, le parent doit parfois livrer une adresse de glue afin d'éviter une résolution circulaire. Les observations reprises dans RFC 9199 indiquent que la plupart des résolveurs redemandent alors l'adresse lors du renouvellement du NS, même si un TTL d'adresse plus long semblait encore courir. Hors bailiwick, l'adresse est généralement résolue et conservée indépendamment ; l'expiration du NS ne suffit pas à l'effacer.

Le journal de migration doit par conséquent mentionner les anciens et nouveaux noms, leurs anciennes et nouvelles adresses, les TTL NS au parent et à l'enfant, les TTL A/AAAA, la classification de bailiwick et l'heure du dernier remplissage possible. Une seule colonne « TTL de la zone » masque précisément le risque à maîtriser.

RFC 2181 organise la crédibilité des données DNS selon leur provenance. Cette hiérarchie n'offre pas pour autant un bouton d'écrasement global. Le parent est faisant autorité pour sa zone et sa délégation ; l'enfant l'est pour les données de sa zone. Un résolveur peut conserver une donnée apprise légitimement jusqu'à son échéance. Dire que la réponse enfant est « plus récente » n'abrège pas matériellement une copie parent encore valide.

Une extinction se prouve depuis les chemins qui restent

La preuve commence avant le changement. Il faut photographier les RRsets NS parent et enfant, les adresses, les TTL et l'instant où les valeurs réduites deviennent effectivement faisant autorité. On calcule ensuite le dernier instant auquel chaque ancienne valeur pouvait encore remplir un cache, puis on maintient les deux infrastructures au-delà de cette limite.

Les sondes doivent varier. Pour chacune : résolveur et version lorsque disponibles, point d'observation, heure de requête, réponse obtenue, TTL restant et serveur finalement interrogé. Le premier constat du nouveau chemin est moins important que le dernier constat de l'ancien, ventilé par comportement de cache et par type d'adresse.

Le silence du serveur ancien n'est qu'un indice. Il peut signifier que les résolveurs échantillonnés l'ont quitté ; il ne démontre pas qu'aucun cache valide ne le désigne encore. Un grand résolveur public ne représente pas tous les logiciels ni toutes les politiques. Les inconnues — parent non maîtrisé, cache non identifiable, service de réponses périmées — doivent rester inscrites comme inconnues.

Après l'arrêt, une vérification distincte confirme que chaque classe pertinente obtient la délégation, résout l'adresse et atteint un serveur faisant autorité. La publication du changement était une instruction. La disparition observée de l'ancien chemin est le reçu.

L'auteur, le protocole et l'opérateur n'ont pas le même mandat

RFC 9199 est signé par Moura, Hardaker, Heidemann et Davids. Il appartient à l'Independent Stream, porte le statut Informational et ne représente ni consensus IETF ni norme Internet. Le profil IETF capturé de Wes Hardaker relie ce travail à une trajectoire de recherche DNS, de participation à l'IETF et d'exploitation de B-root ; il ne lui attribue ni l'étude entière ni le contrôle des résolveurs.

La lecture de Heng Lu aide à distribuer correctement l'agence. Le parent contrôle sa délégation. L'enfant contrôle sa copie. Les auteurs de résolveurs choisissent leur comportement de cache dans les limites communes. L'exploitant de l'infrastructure décide du retrait. Aucun de ces acteurs ne peut promettre la décision des autres.

Les premiers RFC DNS définissent un socle interopérable sans centraliser toutes les décisions futures. Cette spécification minimale rend possible une évolution locale ; elle exige en retour que le code en service tranche les hypothèses. Les traces de résolveur, journaux de requêtes et captures de publication disent quelle branche s'est produite ici.

Un registre partagé coordonne ces preuves sans devenir une autorité générale. Sa fonction est plus modeste : empêcher qu'une horloge parent, enfant ou adresse soit effacée du dossier. L'ancien serveur reste allumé jusqu'à ce que le futur ait atteint les caches encore autorisés à vivre dans le passé.

Sources