Combien de temps dure la propagation DNS, et comment la vérifier

Quand un navigateur a besoin de example.com, il interroge un résolveur récursif : celui de votre FAI, de votre entreprise ou un résolveur public comme Google ou Cloudflare. Le résolveur interroge les serveurs de noms faisant autorité pour le domaine et garde la réponse en cache aussi longtemps que le TTL (durée de vie) de l’enregistrement le permet. Tant que cette copie n’a pas expiré, il continue de servir l’ancienne réponse, même si vous venez de modifier l’enregistrement.

La « propagation », ce sont donc simplement des milliers de caches qui expirent à des moments différents. Un résolveur qui a consulté votre domaine une seconde avant le changement garde l’ancienne réponse pendant un TTL complet. Un résolveur qui ne l’a jamais consulté obtient tout de suite la nouvelle. C’est pourquoi un ami voit déjà le nouveau site alors que vous voyez encore l’ancien.

Le chiffre de « 24 à 48 heures » qu’on lit partout vient des changements de serveurs de noms et de l’époque où les TTL longs étaient la norme. Pour un enregistrement A modifié avec un TTL de 300 secondes, presque tout le monde voit le nouveau serveur en quelques minutes.

• Vous avez réduit le TTL trop tard. Réduire le TTL n’aide qu’une fois l’ancien TTL, plus long, expiré dans les caches. Réduisez-le la veille : voir Réduire le TTL avant une migration.
• Les caches locaux. Votre système d’exploitation et votre navigateur mettent aussi le DNS en cache. Videz-les avant de conclure que la propagation est bloquée.
• Un enregistrement oublié. www pointe encore vers l’ancien serveur, ou un ancien enregistrement AAAA (IPv6) continue d’y envoyer les visiteurs en IPv6.
• Un CDN ou un proxy devant le site. Si Cloudflare ou un autre proxy est placé devant, la réponse DNS est l’adresse du CDN et ne change pas. C’est le réglage d’origine dans le CDN qu’il faut modifier, et Cloudflare l’applique en quelques secondes : il n’y a donc rien à propager. Vérifiez plutôt le nouveau serveur avec un lien d’aperçu.
• Des résolveurs qui gardent les réponses plus longtemps que le TTL. Il y en a quelques-uns. Ils sont minoritaires, et c’est pour cela qu’on laisse tourner l’ancien serveur un ou deux jours après la bascule.

1. 1

   Étape 1 : Confirmer le changement sur les serveurs de noms faisant autorité

   Interrogez les serveurs de noms du domaine. S’ils renvoient encore l’ancienne valeur, l’enregistrement n’a pas été sauvegardé et attendre ne servira à rien.

2. 2

   Étape 2 : Interroger des résolveurs publics dans le monde

   Saisissez le domaine et la valeur attendue dans le vérificateur de propagation DNS pour voir quels résolveurs la renvoient déjà.

3. 3

   Étape 3 : Vérifier chaque nom d’hôte et type d’enregistrement

   Recommencez pour www, les autres sous-domaines et les enregistrements AAAA. Un enregistrement oublié est la cause la plus fréquente d’un changement qui semble bloqué.

4. 4

   Étape 4 : Vider vos propres caches

   Videz le cache DNS du système d’exploitation et redémarrez le navigateur avant de tester le site vous-même.

5. 5

   Étape 5 : Confirmer que le site répond depuis le nouveau serveur

   Utilisez Mon domaine est-il basculé ? pour vérifier que le domaine pointe vers la nouvelle IP et que le site y répond.

6. 6

   Étape 6 : Être prévenu au lieu de rafraîchir

   Activez les alertes de propagation DNS pour le lien d’aperçu : DNSPeek vérifie toutes les quelques minutes et vous envoie un e-mail une fois le changement terminé.

Interrogez directement des résolveurs publics précis. Le nombre affiché dans la section de réponse est le TTL restant de la réponse en cache, en secondes :

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +noall +answer

Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1

Pour voir ce que répondent les serveurs de noms faisant autorité, sans aucun cache, interrogez-les directement. Trouvez-les avec dig NS example.com +short ou le vérificateur de serveurs de noms, puis lancez dig @ns1.your-dns-host.com example.com A. Si même la réponse faisant autorité est ancienne, le changement n’a pas été enregistré.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Il n’existe pas d’interrupteur global qui bascule d’un coup, il faut donc choisir une règle. DNSPeek utilise celle-ci : la propagation est terminée quand au moins 90 % des résolveurs publics qui ont répondu renvoient la nouvelle valeur, et qu’au moins la moitié de tous les résolveurs a répondu. Les résolveurs qui ne répondent pas à temps sont ignorés, pour qu’un seul résolveur injoignable ne vous bloque pas. Le TTL le plus élevé encore observé indique combien de temps un cache obsolète peut encore durer. Quand la nouvelle valeur est une adresse Cloudflare, toute adresse Cloudflare compte, car Cloudflare attribue à chaque région sa propre IP edge.

Le vérificateur de propagation DNS gratuit applique cette règle à 20 résolveurs publics, interrogés depuis le serveur de DNSPeek. Dans le tableau de bord, un lien d’aperçu peut vérifier 16 résolveurs à la demande, et sur les forfaits payants DNSPeek peut vous alerter par e-mail ou webhook une fois le domaine propagé, puis relancer votre rapport QA sur le domaine en production.

Obtenir l’ancienne adresse d’un résolveur et la nouvelle d’un autre est normal à mi-parcours. Chaque résolveur a mis l’enregistrement en cache à un moment différent, et chacun le voit donc expirer à un moment différent. Les grands résolveurs publics font aussi tourner de nombreux caches distincts derrière une même adresse : deux requêtes au même résolveur à une minute d’intervalle peuvent donc différer.

Ne vous inquiétez que si la répartition ne bouge pas. Si la part de nouvelles réponses reste identique plus longtemps que l’ancien TTL, cherchez un enregistrement non modifié, un second jeu de serveurs de noms qui sert encore l’ancienne zone, ou un CDN qui répond pour le domaine. L’outil Comparateur DNS montre si deux serveurs de noms renvoient des enregistrements différents.

La propagation n’est stressante que si le nouveau serveur n’a pas été vérifié avant. Si vous avez ouvert le site sur la nouvelle IP avec un lien d’aperçu avant la bascule, l’attente signifie seulement que certains visiteurs voient l’ancienne copie un peu plus longtemps. Gardez le même contenu sur les deux serveurs, évitez de modifier le contenu de l’ancien et surveillez ses journaux d’accès : quand les vrais visiteurs n’y arrivent plus, vous pouvez l’éteindre sans risque.