La propagation DNS désigne le temps nécessaire pour que les résolveurs du monde entier abandonnent l’ancienne réponse en cache et lisent la nouvelle. Sa durée dépend du TTL, qui fixe la mise en cache maximale, et, pour des serveurs de noms, du TTL de la zone parente. Vérifiez-la avec dig sur plusieurs résolveurs.
Il n’existe pas de diffusion mondiale d’un changement DNS. Chaque résolveur interroge les serveurs de noms faisant autorité, garde la réponse en mémoire pendant la durée du TTL, puis la redemande. Après un changement d’hébergeur, de serveur ou de DNS, des visiteurs voient donc le nouveau site pendant que d’autres atteignent encore l’ancien : chacun dépend du cache de son propre résolveur.
Quand le décalage dure plus longtemps que le TTL ne l’explique, la cause n’est plus la propagation mais une erreur : serveurs de noms mal déclarés, enregistrement mal saisi, ancien enregistrement AAAA, cache local ou DNSSEC incohérent. Si le navigateur affiche plutôt que le nom n’existe pas, le guide sur DNS_PROBE_FINISHED_NXDOMAIN traite ce cas précis.
Relever le TTL et les valeurs attendues
Notez l’adresse IP ou les serveurs de noms que vous avez configurés, puis lisez le TTL actuel avec dig exemple.fr A. Le nombre affiché dans la réponse, avant IN A, est le TTL en secondes tel que le voit le résolveur interrogé. Il décroît à chaque requête tant que la réponse vient du cache : c’est la durée restante avant que ce résolveur ne redemande l’information. Avec dig exemple.fr A @ns1.exemple.net, remplacez le nom par l’un de vos serveurs de noms : le TTL affiché est alors celui de la zone.
Interroger plusieurs résolveurs
Comparez ce que répondent des résolveurs différents : dig +short exemple.fr A @1.1.1.1, dig +short exemple.fr A @8.8.8.8 et dig +short exemple.fr A @9.9.9.9. Sous Windows, nslookup exemple.fr 1.1.1.1 fait la même chose. Si tous renvoient la nouvelle valeur, la propagation est terminée et le décalage vient de votre poste ou de votre réseau. Si seuls certains renvoient l’ancienne, le cache expire progressivement. Des outils web de vérification de propagation interrogent des dizaines de résolveurs à la fois, mais ils ne remplacent pas un test sur le résolveur de vos visiteurs.
Vérifier les serveurs de noms chez le registrar
Lancez dig NS exemple.fr puis dig +trace exemple.fr. La seconde commande part des serveurs racine et suit la délégation étape par étape, sans passer par un cache. Les serveurs de noms affichés doivent être ceux du fournisseur chez qui vous modifiez réellement la zone. Après une migration, il arrive que le registrar déclare encore les anciens serveurs : vos modifications dans la nouvelle zone n’ont alors aucun effet visible, quelle que soit l’attente.
Corriger la zone et le registrar
Dans l’interface du registrar, alignez les serveurs de noms sur ceux de la zone active. Dans la zone, contrôlez chaque enregistrement : adresse IP du A sans faute de frappe, cible du CNAME complète, absence de doublon. Un enregistrement AAAA hérité de l’ancien serveur est un classique : les visiteurs équipés d’IPv6 atteignent l’ancien hébergement alors que les autres voient le nouveau. Supprimez-le ou remplacez-le par l’adresse IPv6 du nouveau serveur. Si vous utilisez DNSSEC, un changement d’hébergeur DNS sans mise à jour de l’enregistrement DS chez le registrar fait échouer la validation : les résolveurs validants rejettent alors le domaine alors que les autres répondent.
Vider les caches locaux
Un poste peut garder l’ancienne réponse même quand le reste du monde a basculé. Sous Windows, tapez ipconfig /flushdns. Sous macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Sous Linux avec systemd-resolved, resolvectl flush-caches. Redémarrez ensuite le navigateur, qui garde son propre cache. Le fichier hosts du poste peut aussi forcer une ancienne adresse : relisez-le si le résultat reste incohérent.
Contourner le cache de votre box ou de votre réseau
Le résolveur de votre fournisseur d’accès ou de votre entreprise a son propre cache, que vous ne pouvez pas vider. Testez le site depuis la 4G d’un téléphone avec le Wi-Fi coupé, ou interrogez un résolveur public comme à l’étape 2. Si le site s’affiche ainsi, la propagation est faite : seul ce résolveur est en retard et expirera de lui-même.
Baisser le TTL avant un changement prévu
Pour une migration à venir, abaissez le TTL des enregistrements concernés bien avant la bascule, au moins aussi longtemps que l’ancien TTL, afin que les caches adoptent la valeur courte. Effectuez le changement, vérifiez, puis remontez le TTL. Cette précaution est la seule vraie façon d’accélérer la propagation : aucun outil ne force les résolveurs des autres à oublier une réponse.
Garder l’ancien serveur actif pendant la transition
Tant que des résolveurs servent l’ancienne adresse, l’ancien serveur reçoit encore des visiteurs. Laissez-le en ligne avec le même contenu, ou une redirection, jusqu’à ce que les requêtes cessent. Ne modifiez pas la zone à chaque test : chaque changement relance un cycle de cache. Pour une messagerie, les mêmes règles s’appliquent aux enregistrements MX : voir le guide sur les e-mails en spam pour SPF, DKIM et DMARC après un changement.
Questions fréquentes
Pourquoi mon site s’affiche-t-il chez moi mais pas chez un collègue ?
Vos deux résolveurs ne sont pas au même point de leur cache. L’un a déjà lu la nouvelle réponse, l’autre conserve l’ancienne jusqu’à l’expiration du TTL. Comparez avec dig +short exemple.fr A @1.1.1.1 depuis chaque poste, puis videz le cache local de celui qui est en retard.
Peut-on forcer la propagation DNS ?
Non : un résolveur extérieur garde sa réponse jusqu’à la fin du TTL et personne ne peut l’en dispenser. Vous pouvez seulement réduire l’attente en abaissant le TTL avant le changement, et vider les caches que vous contrôlez : votre poste, votre navigateur, votre routeur.
Un outil de propagation montre des résolveurs rouges, est-ce grave ?
Pas forcément. Ces outils interrogent des résolveurs variés, dont certains en retard ou mal alimentés. Si les résolveurs publics courants et dig +trace renvoient la bonne valeur, la zone est correcte. Un résolveur resté rouge très longtemps après le TTL doit en revanche faire vérifier DNSSEC et les serveurs de noms.
Changer de serveurs de noms est-il plus long qu’un simple enregistrement A ?
Souvent oui : la délégation est stockée dans la zone parente, par exemple la zone .fr, avec son propre TTL, en plus du TTL des enregistrements. Les deux délais se cumulent selon l’état du cache de chaque résolveur. Gardez l’ancienne zone complète pendant la transition.
Le HTTPS peut-il échouer pendant la propagation ?
Oui. Un visiteur dirigé vers l’ancien serveur reçoit le certificat de ce serveur, qui peut ne pas couvrir le domaine ou être expiré, d’où une alerte de sécurité. Elle disparaît quand le résolveur adopte la nouvelle adresse. Voir le guide sur le certificat SSL expiré.
Sources
- RFC 1034 : Domain names, concepts and facilities — rfc-editor.org
- RFC 2308 : Negative Caching of DNS Queries — rfc-editor.org
- Le TTL d’un enregistrement DNS — Cloudflare