Guide
TTL, caches et propagation DNS
La propagation n’est pas une vague qui avance sur une carte. C’est l’ensemble des caches qui gardent l’ancienne réponse jusqu’à expiration du TTL qu’ils ont reçu.
Ce que mesure le TTL
Le TTL est un nombre de secondes choisi dans la zone, enregistrement par enregistrement. Un résolveur qui reçoit la réponse a le droit de la resservir sans redemander, jusqu’à ce que ce compte à rebours tombe à zéro. Il peut l’oublier plus tôt. Il n’est pas censé l’allonger. Quand vous abaissez un TTL juste avant une migration, vous n’accélérez pas les caches qui ont déjà l’ancien TTL long : vous préparez seulement la suite. Il faut donc baisser le TTL, attendre l’ancien délai, puis changer la valeur.
Le chiffre vu chez un résolveur public n’est en général plus celui de la zone. C’est le reste. Le 23 octobre 2026, les adresses A d’example.com étaient les mêmes partout, mais les TTL affichés étaient 66 s chez 1.1.1.1, 300 s chez 8.8.8.8, 236 s chez 9.9.9.9 et 113 s chez 94.140.14.14. L’autoritatif annonçait 300 s. AdGuard DNS venait de remplir son cache. Google venait de le faire, ou servait encore le TTL plein. Aucune de ces durées n’indique une « distance » géographique.
Un TTL de 300 secondes rend un changement d’adresse rapide et multiplie les questions vers la zone. Un TTL de 86400 secondes, fréquent pour des NS, rend la délégation stable et une erreur de NS longue à effacer. Le bon chiffre dépend de la fréquence réelle des changements, pas d’une mode. Avant une bascule, 300 ou 120 secondes sont courants. Après la bascule, on peut remonter.
Où se trouvent les caches
Il n’y a pas un cache mondial. Il y en a au moins trois étages. Le résolveur récursif (public ou de fournisseur d’accès) garde la réponse. Le résolveur du réseau local peut relayer et parfois garder lui aussi. Le système d’exploitation et parfois l’application gardent une copie encore plus courte. Vider « le cache DNS » sur un poste ne vide pas 1.1.1.1. Vider le cache d’un résolveur que vous ne gèrez pas est impossible : on attend le TTL.
Les réponses négatives sont cachées aussi. Un NXDOMAIN ou un NODATA s’accompagne du SOA, et le champ minimum de ce SOA plafonne la durée. Pour wikipedia.org, ce minimum valait 3600 secondes le 23 octobre 2026. Un nom demandé trop tôt, avant la création de l’enregistrement, peut donc rester « absent » une heure dans un résolveur, alors que la zone le publie déjà. C’est une cause fréquente de « j’ai créé le sous-domaine et il n’existe pas ».
Les NS et les délégations ont leur cache propre, souvent long. On peut avoir un A déjà neuf chez un résolveur qui a redemandé la zone, et d’anciens NS chez un autre qui n’a pas encore refait la délégation. Comparer uniquement le A ne montre pas ce décalage. Il faut aussi demander le type NS, comme l’explique le guide délégation, NS et registraire.
Ce que « propagation » décrit mal
On dit qu’un changement « se propage » parce que les observateurs ne le voient pas tous à la même minute. L’image d’une onde est trompeuse. Rien ne parcourt les opérateurs dans un ordre fixé. Chaque cache expire selon l’instant où il a appris l’ancienne valeur. Deux personnes chez le même résolveur voient la même chose. Deux résolveurs voisins peuvent différer de tout le TTL.
Le verdict « divergence de propagation » de l’outil correspond à ce cas : les valeurs, pas seulement les TTL, diffèrent entre les sources interrogées. Des TTL différents avec les mêmes adresses ne suffisent pas à conclure à une divergence. Des adresses différentes, ou un NXDOMAIN d’un côté et un NOERROR avec données de l’autre, oui. La référence du contenu publié maintenant est la réponse autoritative, drapeau aa, pas la majorité des résolveurs. La majorité dit ce que voient les utilisateurs de ces résolveurs.
Si les autoritatifs montrent déjà la nouvelle valeur et qu’un résolveur montre l’ancienne, il reste à attendre ou à utiliser un autre résolveur. Si les autoritatifs montrent encore l’ancienne valeur, le changement n’est pas dans la zone : l’interface n’a pas enregistré, le mauvais compte a été modifié, ou un autre service d’hébergement DNS est encore délégué. Attendre la « fin de la propagation » ne corrigera pas une zone qui n’a pas changé.
Préparer un changement
Notez le TTL actuel et les valeurs vues chez au moins un autoritatif et deux résolveurs. Baissez le TTL si la bascule doit être réversible vite. Attendez l’ancien TTL. Faites la modification. Recontrôlez d’abord l’autoritatif : c’est lui qui doit montrer la nouvelle donnée et le nouveau TTL. Ensuite seulement, regardez les résolveurs. Un résolveur encore ancien n’est pas un échec de la modification.
Évitez de changer en même temps les NS et les adresses si vous pouvez l’ordonner. Une délégation fraîche vers des NS qui n’ont pas encore la zone produit des échecs, pas un simple délai. Le diagnostic des pannes distingue ce SERVFAIL d’un NXDOMAIN de cache. DNSSEC ajoute une contrainte : le DS du parent doit suivre les clés, sinon les résolveurs validants refusent la zone neuve comme l’ancienne. Voir le guide DNSSEC.
Pendant l’attente, les deux jeux d’adresses doivent répondre de la même façon si vous voulez une bascule invisible : ancien serveur encore allumé, nouveau serveur déjà prêt. Le DNS ne fait pas la synchronisation des contenus. Il indique seulement quelle adresse est autorisée à être annoncée à un instant donné. L’outil sert à photographier cet instant sur quatre résolveurs et sur les NS.