Propagation DNS

Le DNS ne dispose d'aucune base centrale que chaque serveur consulterait en temps réel. Les serveurs faisant autorité détiennent les enregistrements à jour, mais les résolveurs récursifs répartis dans le monde - ceux des fournisseurs d'accès ou des services publics comme Cloudflare ou Google - ne rafraîchissent leur copie en cache que lorsqu'elle expire. Tant que ce délai n'est pas écoulé, le résolveur continue de renvoyer sa version en cache, même si la réponse faisant autorité a changé une heure plus tôt.

Ce délai de mise en cache correspond au TTL (Time To Live) défini sur chaque enregistrement, exprimé en secondes. Un enregistrement avec un TTL de 3600 peut rester en cache jusqu'à une heure chez un résolveur qui l'a interrogé juste avant. Deux résolveurs ayant interrogé le domaine à des moments différents conservent le même enregistrement mais l'expirent à des instants différents - d'où le fait qu'une vérification lancée cinq minutes après un changement DNS montre presque toujours certains serveurs déjà à jour et d'autres encore sur l'ancienne valeur.

Ce n'est ni un bug du DNS ni un signe de blocage : c'est le modèle de cache qui fonctionne comme prévu. La RFC 1035 définit le TTL comme une indication donnée à tout résolveur de cache, et la RFC 2181 précise qu'il s'applique à l'enregistrement lui-même, pas à une réponse en particulier - chaque résolveur décide indépendamment quand sa copie est périmée.

• Un résolveur ne réinterroge jamais avant l'expiration du TTL qu'il a mis en cache, quelle que soit l'urgence perçue du côté de qui a fait le changement
• Baisser le TTL avant un changement planifié réduit le pire des cas d'attente, mais il faut le baisser en amont - le modifier en même temps que l'enregistrement n'accélère rien pour ce premier changement
• Ce sont les résolveurs récursifs, pas les serveurs faisant autorité, que mesure réellement la "propagation" - côté autorité, la mise à jour est immédiate
• Un enregistrement dont le TTL n'a pas été anticipé peut mettre jusqu'à la totalité de son TTL pour être cohérent partout, et certains résolveurs locaux ou caches côté FAI dépassent parfois ce délai

Chaque ligne des résultats correspond à un résolveur public interrogé directement, regroupé par région - on retrouve typiquement des fournisseurs comme Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, ainsi que des opérateurs régionaux en Amérique du Nord, en Europe et en Asie. Un serveur peut renvoyer trois états : réponse réussie, erreur (refus, erreur de format, échec serveur), ou absence de réponse dans le délai imparti. Un délai dépassé ne signifie pas que l'enregistrement est absent - le plus souvent, ce résolveur précis était momentanément injoignable ou lent, et une nouvelle tentative quelques instants plus tard aboutit.

Le résumé en tête de page indique un pourcentage de résolveurs ayant répondu avec succès, ainsi que le niveau de cohérence entre eux. Cette cohérence compte davantage que le pourcentage isolé : 100 % de résolveurs répondant, mais répartis sur deux jeux d'enregistrements différents, signifie que le changement n'est pas encore propagé partout. Les résultats regroupent les réponses par jeux identiques - les résolveurs renvoyant exactement le même ensemble d'enregistrements sont réunis dans un même groupe, ce qui fait qu'un domaine en cours de propagation affiche typiquement un groupe avec l'ancienne valeur et un autre avec la nouvelle.

Un domaine sans aucun enregistrement pour le type interrogé (une recherche A vide sur un domaine qui n'a qu'un AAAA, par exemple) apparaît comme un groupe distinct "sans enregistrement" plutôt que comme une erreur - c'est une réponse cohérente et légitime dès lors que tous les résolveurs s'accordent dessus.

Le TTL de l'enregistrement modifié fixe un plafond, pas une moyenne. Si l'ancien TTL était de 86400 (24 heures), un résolveur ayant mis en cache l'ancien enregistrement 23 heures avant le changement le conservera encore une heure, quel que soit le moment de la vérification. Ce même résolveur, s'il avait interrogé le domaine une minute avant le changement, le réinterrogera presque immédiatement. C'est pourquoi les vérifications menées juste après une modification montrent souvent un large éventail de résultats dans les premières heures, avant de converger - chaque résolveur expire son propre cache selon son propre calendrier, pas sur une horloge synchronisée.

Modifier le TTL lui-même ne profite qu'au prochain changement. Faire passer un TTL de 86400 à 300 secondes ne prend effet qu'une fois les résolveurs remis en cache avec cette nouvelle valeur - ce qui reste soumis à l'ancien TTL. La pratique standard : baisser le TTL bien avant une bascule planifiée, attendre que cette valeur plus courte se soit installée partout, effectuer le changement, puis remonter le TTL une fois le déploiement stable.

Un changement au niveau du registrar - changer les serveurs de noms chez le registrar plutôt que modifier un enregistrement chez l'hébergeur DNS - suit un chemin distinct et plus lent : la zone parente met elle aussi en cache la délégation NS, et le TTL de cette délégation est fixé par le registre, pas par qui gère le DNS. Attendre est le seul levier disponible ici, un cas fréquent lors d'un transfert de domaine chez un registrar français comme OVHcloud ou Gandi.