fren
Connexion

Comprendre la propagation DNS

3 min de lecture07 novembre 2026

Après un changement DNS, deux personnes voient parfois deux réponses différentes : l'une le nouveau serveur, l'autre l'ancien. On appelle cela la propagation, alors qu'il s'agit simplement de caches qui expirent à des moments différents. Le délai est prévisible si vous connaissez le TTL.

Ce qui se passe réellement

Votre modification est enregistrée immédiatement sur le serveur faisant autorité. Ensuite, chaque résolveur qui possède déjà l'ancienne réponse la conserve jusqu'à la fin de son TTL. Il n'existe aucune diffusion vers tous les résolveurs du monde.

Trois couches peuvent conserver une réponse :

  • le résolveur du fournisseur d'accès ou de l'entreprise ;
  • un résolveur public comme 1.1.1.1 ou 8.8.8.8 ;
  • le système local, y compris systemd-resolved sur Linux ou le cache DNS du navigateur.

Le cache négatif s'applique aussi : une erreur « ce nom n'existe pas » reste mémorisée selon le champ minimum du SOA, souvent plusieurs minutes.

Délais réalistes selon le TTL

TTL avant le changement Délai maximal théorique Remarque
300 s 5 minutes bon réglage de transition
3600 s 1 heure défaut courant
86400 s 24 heures à éviter avant migration

À cela s'ajoute le temps de propagation de la délégation si vous changez de serveurs DNS : le TTL des NS chez l'extension s'applique, et certains résolveurs le prolongent.

La bonne séquence consiste à baisser le TTL à 300 au moins 24 heures avant (idéalement 48 heures, pour laisser expirer l'ancien TTL), puis à effectuer le changement.

Vérifier sans se tromper

Interrogez d'abord l'autorité, qui détient la vérité :

Bash
dig @ns1.fournisseur.fr A votre-domaine.fr +short

Puis plusieurs résolveurs publics, pour voir ce que voient vos visiteurs :

Bash
dig @1.1.1.1 A votre-domaine.fr +short
dig @8.8.8.8 A votre-domaine.fr +short

La commande dig +trace montre la délégation, utile quand les NS eux-mêmes ont changé. Les sites de vérification qui affichent une carte du monde interrogent simplement de nombreux résolveurs : ils mesurent des caches, pas une propagation.

Pour tester un serveur sans attendre le DNS, utilisez curl --resolve :

Bash
curl -sI --resolve votre-domaine.fr:443:[VOTRE_IPV6] https://votre-domaine.fr/ | head -n 5

Purger les caches locaux

Si votre machine affiche encore l'ancienne adresse alors que les résolveurs publics sont à jour, videz le cache local.

Sur Debian avec systemd-resolved :

Bash
sudo resolvectl flush-caches
resolvectl status

Avec unbound ou dnsmasq, redémarrez le service correspondant. Sur macOS, utilisez sudo dscacheutil -flushcache puis sudo killall -HUP mDNSResponder. Sur Windows, ipconfig /flushdns. Dans le navigateur, un cache DNS interne peut subsister : testez en navigation privée ou redémarrez-le.

Bonnes pratiques

  • Ne changez pas le TTL et la valeur d'un enregistrement au même instant : faites-le en deux temps.
  • Gardez l'ancien serveur en ligne jusqu'à l'expiration du TTL, sinon les visiteurs encore sur l'ancienne adresse tombent sur une erreur.
  • Modifiez les enregistrements mail en période calme et surveillez les rejets pendant 48 heures.
  • Documentez l'heure du changement et le TTL appliqué : le diagnostic devient trivial la fois suivante.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi