Pourquoi un changement DNS prend du temps : TTL et propagation

Ce que signifie vraiment la propagation DNS

« Propagation » est le mauvais mot, et c'est de là que vient la confusion. Rien n'est diffusé à travers internet. Quand vous modifiez un enregistrement chez votre hébergeur DNS, le changement est actif sur vos serveurs faisant autorité immédiatement, en quelques secondes.

Ce qui prend du temps, c'est l'inverse : des résolveurs partout dans le monde conservent encore l'ancienne réponse, parce que vous les y avez autorisés. Chaque enregistrement porte un TTL, une durée de vie, et un résolveur qui l'a récupéré peut servir cette copie en cache jusqu'à expiration. Il ne redemandera pas avant, puisque vous avez dit que ce n'était pas nécessaire.

La bonne question n'est donc jamais « est-ce que ça s'est propagé ? ». C'est « quel cache garde encore l'ancienne réponse, et quand expire-t-il ? ». Cette question a une réponse précise, et vous pouvez la consulter.

Comment fonctionne réellement le TTL

Le TTL est un nombre de secondes attaché à chaque enregistrement. Ce n'est pas une suggestion, c'est le contrat. Un enregistrement avec un TTL de 3600 dit à chaque résolveur : cette réponse est valable une heure, ne revenez pas avant.

Trois détails déroutent souvent :

• Le compte à rebours démarre quand le résolveur met en cache, pas quand vous faites le changement. Un résolveur qui a récupéré votre enregistrement il y a 50 minutes avec un TTL de 3600 se rafraîchira dans 10 minutes. Un autre, interrogé il y a 5 minutes, attendra 55. D'où l'apparition du changement bien plus tôt pour certains.
• Le TTL qui compte est l'ancien. Baisser le TTL au moment même où vous changez la valeur ne raccourcit rien, car les résolveurs honorent encore le TTL reçu la fois précédente. Le nouveau ne s'applique qu'à partir du rafraîchissement suivant.
• Le TTL est par enregistrement, pas par domaine. Votre enregistrement A et votre MX peuvent expirer à des heures d'écart.

Quels caches gardent l'ancienne réponse

Il y a rarement un seul cache entre un visiteur et votre serveur de noms. Quand un changement semble bloqué, mieux vaut savoir quelle couche blâmer.

• Le résolveur récursif : celui de votre opérateur, ou un public comme Cloudflare ou Google. C'est le cache que le TTL gouverne, et c'est souvent la vraie réponse au « pourquoi mon collègue le voit et pas moi ».
• Le système d'exploitation garde son propre petit cache. Le vider est la seule étape réellement sous votre contrôle.
• Le navigateur met encore en cache séparément, et Chrome en particulier conserve une entrée bien au-delà d'un TTL court. Un autre navigateur, ou une fenêtre privée, permet d'écarter cette piste.
• Votre routeur peut exécuter un résolveur relais qui met en cache par-dessus tout le reste.

Tester depuis une seule machine ne dit donc presque rien. Interrogez plusieurs résolveurs publics et comparez : c'est à cela que sert un outil de requête DNS.

Combien de temps cela prend vraiment

La réponse honnête : pas plus que le TTL précédent, pour la grande majorité des visiteurs. Le chiffre de « 24 à 48 heures » répété partout vient d'une époque de TTL bien plus longs ; il est aujourd'hui faux bien plus souvent que vrai.

• TTL 300 (5 minutes) : pratiquement instantané. Courant pour les enregistrements modifiés souvent.
• TTL 3600 (1 heure) : une valeur par défaut très répandue. La plupart des visiteurs voient le changement dans l'heure.
• TTL 86400 (24 heures) : encore la valeur par défaut chez certains registrars, et la vraie source du conseil « attendez un jour ».

Deux cas peuvent réellement durer plus longtemps. Un changement de serveurs de noms chez le registrar touche les enregistrements du TLD, qui ont leur propre TTL, souvent 48 heures. Et quelques résolveurs ignorent les TTL courts en imposant un plancher, d'où une minorité tenace en retard sur tout le monde.

Changer un enregistrement sans coupure

L'attente n'est un problème que si vous ne l'avez pas prévue. La séquence ci-dessous la supprime presque entièrement, au prix d'une étape supplémentaire.

Baissez d'abord le TTL, puis attendez

Au moins une période complète de l'ancien TTL avant le changement, passez le TTL à 300. Puis attendez l'expiration de l'ancien TTL. C'est l'étape que tout le monde saute et la seule qui compte : vous payez l'attente à l'avance, pendant que l'ancienne valeur est encore correcte et que personne n'est affecté.

Faites le changement

Modifiez maintenant la valeur. Comme chaque résolveur se rafraîchit toutes les cinq minutes, la nouvelle réponse atteint le monde en à peu près ce délai.

Vérifiez ailleurs que sur votre machine

Contrôlez auprès de plusieurs résolveurs publics plutôt que de recharger votre navigateur. Votre ordinateur est le témoin le moins fiable dont vous disposez.

Remettez le TTL

Une fois le changement confirmé, remontez le TTL à une valeur raisonnable : 3600 ou plus. Tout laisser à 300 pour toujours, c'est plus de requêtes, des premiers chargements un peu plus lents et aucun cache pour vous protéger si vos serveurs de noms ont un mauvais jour.

Vérifier l'avancement honnêtement

Trois contrôles disent presque tout :

• Comparez les résolveurs. Interrogez Cloudflare, Google et Quad9 sur le même enregistrement. Des réponses différentes signifient que le changement est en cours, pas cassé.
• Lisez le TTL dans la réponse. Un résolveur renvoie les secondes restantes sur sa copie en cache, en décompte. Ce nombre est littéralement la durée pendant laquelle il servira encore l'ancienne réponse.
• Interrogez le type que vous avez modifié. Un MX obsolète n'apparaît pas dans une requête d'enregistrement A.

Vous pouvez faire les trois dans le navigateur avec l' outil DNS Lookup, en changeant de résolveur entre les requêtes et en lisant le TTL de chaque ligne.

Est-ce valable aussi pour MX, TXT et CNAME ?

Oui : le mécanisme est identique pour chaque type, mais les conséquences diffèrent, et cela vaut la peine de le savoir avant d'y toucher.

• Les enregistrements MX demandent de la prudence. Tant qu'un ancien MX est en cache, le courrier part vers l'ancien serveur. Ce courrier n'est pas mis en file d'attente pour vous : il arrive quelque part que vous ne lisez peut-être plus. Baissez le TTL bien avant une migration de messagerie et gardez l'ancienne boîte accessible jusqu'à expiration complète.
• Les enregistrements TXT (SPF, DKIM, vérification de domaine) sont en général les moins douloureux, car une vérification échouée est simplement réessayée. L'exception est SPF : un SPF obsolète peut faire échouer du courrier légitime tant qu'il dure.
• Les enregistrements CNAME ajoutent un second TTL. Le résolveur met en cache votre CNAME, puis séparément l'enregistrement cible, chacun avec son décompte. Votre attente réelle est la plus longue des deux : un CNAME pointant vers un fournisseur au TTL long peut traîner derrière votre propre réglage.
• Les enregistrements NS sont le cas lent décrit plus haut, car la délégation se trouve un niveau au-dessus, dans la zone du TLD.

Quoi que vous ayez changé, interrogez ce type précis plutôt que de supposer. Un MX obsolète est invisible dans une requête A, et le TTL à surveiller est celui de la ligne que vous avez réellement modifiée.

Erreurs courantes

• Baisser le TTL et changer la valeur dans la même édition. L'erreur la plus fréquente, et elle n'apporte rien.
• Juger depuis un seul navigateur. Quatre caches de profondeur : le pire endroit pour tester.
• Changer de serveurs de noms alors qu'on voulait changer un enregistrement. Bien plus lent, et facile à faire par accident en suivant des instructions génériques.
• Laisser le TTL à 300 en permanence après une migration.
• Supposer 24 heures et ne pas vérifier. Avec un TTL d'une heure, c'est généralement réglé en une heure.

En résumé

Votre changement était actif dès l'enregistrement. Ce que vous attendez, c'est l'expiration des caches des autres, et l'ancien TTL vous dit exactement combien de temps. Baissez le TTL avant un changement planifié, vérifiez auprès de résolveurs publics plutôt que dans votre navigateur, et remontez-le ensuite. Consultez les enregistrements actuels d'un domaine et leur TTL restant avec l'outil DNS Lookup gratuit, ou confirmez qu'un certificat a bien suivi vers le nouvel hébergeur avec le vérificateur de certificat SSL.

Outils et guides associés :

• Recherche DNS : Interrogez les enregistrements A, AAAA, MX, TXT, NS et plus, avec valeurs et TTL, ainsi que le DNS inversé.
• Vérificateur de certificats SSL : Vérifiez le certificat SSL de n'importe quel domaine : émetteur, date d'expiration et jours restants.
• Recherche DNS : guide complet pour interroger les enregistrements de domaine : Apprenez à utiliser un outil de recherche DNS pour interroger les enregistrements A

Questions fréquentes