Propagation DNS : pourquoi ça prend des heures et comment vérifier

Les serveurs DNS répartis dans le monde mettent à jour leur cache à des rythmes différents lors d'un changement d'enregistrement

À la une

La propagation DNS dure entre quelques minutes et 48 heures, selon la valeur TTL configurée sur l’ancien enregistrement et la politique de cache des résolveurs intermédiaires. Modifier un enregistrement A ou CNAME ne déclenche pas une diffusion instantanée : chaque serveur DNS récursif dans le monde conserve la réponse précédente jusqu’à expiration de son cache, ce qui explique qu’un site puisse répondre depuis la nouvelle adresse IP pour un visiteur et depuis l’ancienne pour un autre au même moment.

Le terme « propagation » est d’ailleurs trompeur. Aucun mécanisme central ne pousse la mise à jour vers les serveurs du réseau. Chaque résolveur interroge le serveur faisant autorité quand son cache expire, puis stocke la nouvelle réponse pour la durée définie par le TTL (Time To Live). Selon la documentation IBM sur la propagation DNS, ce fonctionnement par expiration de cache est la seule raison pour laquelle la mise à jour prend du temps.

Le TTL, facteur qui détermine réellement le délai

Combien de temps faut-il pour que le DNS se propage ? La réponse dépend presque entièrement du TTL actif avant la modification. Un TTL de 300 secondes (5 minutes) signifie que chaque résolveur rafraîchira sa copie dans les 5 minutes suivant l’expiration. Un TTL de 86 400 secondes (24 heures), courant chez plusieurs hébergeurs par défaut, impose d’attendre jusqu’à une journée complète.

Certains fournisseurs d’accès ajoutent leur propre couche de cache et ne respectent pas toujours le TTL annoncé, ce qui peut prolonger le délai au-delà de la valeur théorique. La RFC 1035 de l’IETF, qui définit le protocole DNS, précise que le TTL est un maximum, pas une garantie de rafraîchissement immédiat à expiration.

Une bonne pratique avant toute migration : abaisser le TTL à 300 secondes au moins 24 à 48 heures avant le changement prévu. Les résolveurs auront alors le temps de prendre en compte cette nouvelle valeur courte, et la bascule effective se fera en quelques minutes le jour J. Remonter le TTL à sa valeur normale après confirmation du bon fonctionnement réduit ensuite la charge sur le serveur faisant autorité. Pour comprendre le rôle de chaque type d’enregistrement concerné, consulter le guide sur les enregistrements DNS A, CNAME, MX et TXT.

Comment tester la propagation depuis plusieurs points du réseau

Comment puis-je tester la propagation de mon DNS ? Le moyen le plus direct consiste à interroger des résolveurs situés dans différentes régions. La commande dig sous Linux ou macOS permet de cibler un serveur précis :

dig @8.8.8.8 exemple.fr A

Remplacer 8.8.8.8 par d’autres résolveurs publics (1.1.1.1 de Cloudflare, 9.9.9.9 de Quad9) donne un aperçu rapide. Sous Windows, nslookup exemple.fr 8.8.8.8 produit le même résultat. Si tous renvoient la nouvelle adresse IP, la propagation est terminée pour la majorité des utilisateurs.

Outil	Usage	Accès
`dig` / `nslookup`	Requête manuelle vers un résolveur choisi	Terminal local
Site24x7 DNS Propagation	Vérification simultanée depuis plus de 50 emplacements	En ligne, gratuit
`host`	Résolution rapide en ligne de commande	Terminal Linux/macOS

Ces vérificateurs en ligne interrogent des dizaines de serveurs répartis sur plusieurs continents et affichent la réponse obtenue par chacun, ce qui permet d’identifier les zones où l’ancien enregistrement persiste.

Voir aussi SPF, DKIM et DMARC : les trois enregistrements qui sauvent vos emails

Que faire quand la propagation semble bloquée

Comment régler le problème de DNS ? Si après 48 heures certains résolveurs renvoient toujours l’ancienne adresse, plusieurs causes sont possibles. Le cache local du système d’exploitation ou du navigateur peut conserver une entrée périmée : vider le cache DNS local (ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache sous macOS) élimine cette hypothèse en quelques secondes. Certains antivirus et VPN maintiennent aussi leur propre cache DNS.

Vérifier ensuite que la zone DNS du domaine pointe bien vers les bons serveurs de noms (NS). Une incohérence entre les NS déclarés chez le registrar et ceux configurés chez l’hébergeur bloque la résolution, indépendamment du TTL. Ce type d’erreur survient fréquemment lors d’un changement d’hébergeur accompagné d’un nouveau certificat SSL.

Pour les sites WordPress, un enregistrement DNS mal configuré après migration peut aussi provoquer une erreur 500 si le domaine pointe vers un serveur qui n’héberge pas encore les fichiers.

Damien Roux

Damien Roux est l'hébergement web. de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress