Propagation DNS : définition et comment limiter son impact

La propagation DNS est le délai pendant lequel certains résolveurs continuent de servir l'ancienne valeur d'un enregistrement après sa modification sur le serveur de noms faisant autorité. Il ne s'agit pas d'une diffusion : chaque résolveur conserve sa réponse en cache jusqu'à la fin du TTL. Le délai va de quelques minutes à 24 ou 48 heures pour un changement de serveurs de noms, selon le TTL de l'enregistrement avant la modification et, pour les serveurs de noms, selon le TTL de délégation du registre. Voici comment cela fonctionne et comment limiter l'impact.

Ce qu'il faut retenir

Votre modification est visible immédiatement sur le serveur faisant autorité. Le délai vient uniquement des caches des résolveurs, qui gardent l'ancienne valeur jusqu'à l'expiration de son TTL.
C'est le TTL en vigueur avant le changement qui fixe la durée de l'ancienne valeur, pas celui que vous venez de saisir. Abaissez-le à l'avance.
Un changement de serveurs de noms est le plus lent, car il dépend du TTL de délégation du registre, que vous ne contrôlez pas.
Les erreurs « ce nom n'existe pas » sont elles aussi mises en cache : visiter un nom avant de créer son enregistrement peut prolonger l'erreur.

Ce que la propagation DNS n'est pas : une diffusion

Le terme est trompeur. Aucun serveur n'envoie votre modification aux autres. Quand vous enregistrez un changement chez votre fournisseur DNS, le serveur de noms faisant autorité de la zone sert la nouvelle valeur tout de suite. Le délai se joue ailleurs, dans les caches.

Quand un poste cherche l'adresse d'un nom de domaine, la demande traverse plusieurs étages, et chacun peut garder la réponse en mémoire :

le navigateur, dont le cache dure en général de l'ordre de la minute et ne respecte pas toujours le TTL ;
le système d'exploitation, qui garde les réponses récentes ;
le résolveur récursif, fourni par votre fournisseur d'accès ou public (par exemple 8.8.8.8 chez Google, 1.1.1.1 chez Cloudflare), qui interroge la hiérarchie DNS puis conserve la réponse.

Chaque résolveur applique le TTL que le serveur faisant autorité lui a indiqué au moment où il a mis la réponse en cache. Comme ils n'ont pas tous interrogé le serveur au même instant, leurs copies expirent à des moments différents. Un enregistrement avec un TTL de 3 600 secondes, mis en cache il y a 5 minutes, sera renouvelé dans 55 minutes. D'où les constats contradictoires : l'un voit le nouveau site, l'autre l'ancien, un troisième une erreur.

Combien de temps dure une propagation DNS

La durée dépend du type de changement. Un TTL d'un jour (86 400 secondes) est courant, et les valeurs sont plus élevées pour les enregistrements qui changent rarement, comme les serveurs de noms.

Type de changement	Durée habituelle	Ce qui la fixe
Modification d'un enregistrement existant (A, AAAA, CNAME, MX, TXT)	Jusqu'à la durée de l'ancien TTL, de quelques minutes à 24 heures selon la configuration	Le TTL en vigueur avant la modification
Création d'un enregistrement qui n'existait pas	Variable, de l'ordre de quelques heures au plus dans la plupart des cas	Le SOA de la zone (TTL du SOA et champ MINIMUM)
Changement de serveurs de noms chez le registrar	De quelques heures à 48 heures	Le TTL de délégation du registre, souvent d'un à deux jours
Résolveur avec ses propres limites	Peut dépasser le TTL annoncé	Un plafond ou un plancher configuré (86 400 s par défaut pour Unbound, 604 800 s pour BIND)

Les trois facteurs qui décident du délai

Le TTL d'avant la modification

Imaginons un enregistrement à 86 400 secondes que vous réglez aujourd'hui à 300 secondes. Un résolveur qui l'a mis en cache hier garde l'ancienne valeur jusqu'à 24 heures, quelle que soit la nouvelle valeur : le TTL de 300 secondes ne s'applique qu'une fois la copie renouvelée. Pour un CNAME, chaque nom de la chaîne a son propre TTL, et le plus long l'emporte sur la durée totale.

La délégation chez le registre

Quand vous changez de serveurs de noms, la modification se fait chez le registrar, qui la transmet au registre du domaine de premier niveau. Les résolveurs qui connaissent encore l'ancienne liste de serveurs de noms continuent à les interroger jusqu'à l'expiration de la délégation. Ce TTL appartient au registre : vous ne pouvez pas le raccourcir.

Les résolveurs qui ne suivent pas le TTL à la lettre

Certains résolveurs plafonnent ou relèvent les TTL, et les navigateurs ont leur propre cache de courte durée. Il est donc impossible de garantir la même durée partout. Le TTL est une borne théorique, pas un engagement de tous les caches.

Le piège du cache négatif

La plupart des guides parlent du TTL des enregistrements et oublient les réponses négatives. Quand un résolveur apprend qu'un nom n'existe pas (réponse NXDOMAIN) ou qu'il n'a pas d'enregistrement du type demandé, il peut mémoriser cette absence. La RFC 2308 fixe la durée du cache négatif à la plus petite des deux valeurs suivantes : le TTL du SOA de la zone et son champ MINIMUM. Elle juge raisonnables des durées d'une à trois heures et signale que des valeurs supérieures à un jour posent problème.

Le scénario type : vous testez nouveau.example.com avant d'avoir créé l'enregistrement, vous obtenez une erreur, puis vous créez l'enregistrement. Pour votre résolveur, le nom « n'existe pas » jusqu'à la fin du cache négatif, même si l'enregistrement est en ligne depuis une minute. Les réflexes pour l'éviter :

créez l'enregistrement avant de tester ou d'annoncer le nom ;
si votre fournisseur DNS permet de régler le SOA, gardez un champ MINIMUM modéré ;
videz votre cache local avant de conclure que « ça ne marche pas » : Microsoft précise que la commande ipconfig /flushdns supprime aussi les entrées de cache négatives.

Méthode pour limiter l'impact d'une migration

Relevez le TTL actuel de chaque enregistrement concerné (voir les commandes plus bas). C'est lui qui fixe le délai.
Abaissez le TTL à 300 secondes, au moins aussi longtemps à l'avance que l'ancien TTL. Avec 86 400 secondes, faites-le 24 à 48 heures avant la bascule. Vérifiez le minimum accepté par votre fournisseur.
Préparez la nouvelle destination : site, serveur de messagerie ou CDN prêt à répondre avec le même contenu que l'ancien. Les deux doivent fonctionner pendant la transition.
Basculez l'enregistrement, une modification à la fois pour savoir quoi vérifier.
Vérifiez d'abord le serveur faisant autorité, puis des résolveurs publics.
Gardez l'ancien serveur actif au moins jusqu'à la fin du plus long ancien TTL, puis seulement coupez-le.
Remontez le TTL (3 600 secondes ou plus) quand tout est stable.

Pour un changement de serveurs de noms, recréez d'abord la zone complète chez le nouveau fournisseur (A, CNAME, MX, TXT dont SPF et DKIM, et tout le reste), vérifiez qu'elle répond correctement, puis modifiez les serveurs de noms chez le registrar. Laissez la zone de l'ancien fournisseur en ligne et identique pendant 48 heures : les résolveurs qui connaissent encore l'ancienne délégation continuent de l'interroger.

Vérifier ce que voit chaque résolveur

La commande dig (macOS, Linux) ou nslookup (Windows) permet de comparer ce que répondent le serveur faisant autorité et plusieurs résolveurs publics.

# Valeur et TTL restant vus par des résolveurs publics
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Serveurs de noms déclarés pour le domaine
dig +short NS example.com

# Valeur servie par le serveur faisant autorité (remplacez par votre serveur de noms)
dig +noall +answer example.com A @ns1.fournisseur-dns.example

# Numéro de série du SOA, à comparer entre serveurs de noms
dig +short SOA example.com @ns1.fournisseur-dns.example
dig +short SOA example.com @ns2.fournisseur-dns.example

# Équivalent sous Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

Dans la réponse d'un résolveur, le TTL affiché diminue d'une requête à l'autre : c'est le temps restant avant l'expiration de la copie. Si un résolveur renvoie l'ancienne valeur avec un TTL qui décroît alors que le serveur faisant autorité renvoie déjà la nouvelle, il suffit d'attendre.

Comparez aussi le numéro de série du SOA entre vos serveurs de noms. S'ils diffèrent, un serveur sert des données périmées : le problème vient de votre fournisseur DNS, pas de la propagation. La page dns.google permet d'interroger un type d'enregistrement précis, dont le SOA, et le guide de dépannage de Google Public DNS détaille cette vérification.

Vider les caches que vous contrôlez

Vider votre propre cache ne change rien pour les autres visiteurs, mais il permet de vérifier ce que vous voyez réellement.

# Windows (invite de commandes)
ipconfig /flushdns

# macOS récent
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux avec systemd-resolved
resolvectl flush-caches

La page de Microsoft sur la commande ipconfig décrit /flushdns et /displaydns. Fermez ensuite complètement le navigateur, qui garde sa propre mémoire de courte durée.

Deux résolveurs publics proposent aussi une purge, utile après un changement de serveurs de noms ou pour les clients qui les utilisent : le Flush Cache de Google Public DNS (Google conseille de purger le domaine enregistré et le nom précis qui renvoie une réponse périmée) et l'outil de purge de cache de 1.1.1.1 de Cloudflare, où l'on choisit le domaine et le type d'enregistrement. Les résolveurs des fournisseurs d'accès ne se purgent pas : il faut attendre l'expiration de leurs copies.

Les erreurs fréquentes

Abaisser le TTL au moment de la bascule. C'est trop tard : les résolveurs gardent la copie faite avec l'ancien TTL.
Tester le nom avant d'avoir créé l'enregistrement. Le cache négatif peut prolonger l'erreur.
Changer les serveurs de noms avant de recréer toute la zone. Les e-mails ou les sous-domaines oubliés cessent de fonctionner pour les résolveurs qui interrogent déjà le nouveau fournisseur.
Couper l'ancien serveur trop tôt. Les visiteurs dont le cache n'a pas expiré tombent sur un serveur qui ne répond plus.
Conclure que la propagation est terminée depuis son propre poste. Votre cache local ne représente pas les autres résolveurs.
Laisser un TTL très bas en permanence. Cela multiplie les requêtes vers vos serveurs de noms. Remontez-le une fois la migration terminée.

Foire aux questions

Combien de temps dure la propagation DNS ?

Pour la modification d'un enregistrement, au plus la durée de l'ancien TTL : une heure avec un TTL de 3 600 secondes, 24 heures avec 86 400 secondes. Pour un changement de serveurs de noms, comptez de quelques heures à 48 heures. La plupart des résolveurs se mettent à jour bien avant la fin du délai maximal. Ce qui reste, ce sont quelques caches retardataires.

Peut-on accélérer la propagation DNS ?

Pas à l'échelle d'Internet : on ne peut pas forcer les caches des autres. On peut abaisser le TTL avant le changement, purger les résolveurs publics de Google et de Cloudflare et vider ses propres caches. Les résolveurs des fournisseurs d'accès ne se purgent pas.

Quel TTL choisir avant une migration ?

Une valeur courte comme 300 secondes (5 minutes), appliquée au moins pendant la durée de l'ancien TTL avant la bascule. Une fois la migration stabilisée, remontez à 3 600 secondes ou plus : un TTL très bas en permanence multiplie les requêtes. Vérifiez le minimum que votre fournisseur DNS accepte.

Pourquoi mon collègue voit-il le nouveau site et pas moi ?

Vous passez par des résolveurs différents, qui ont mis la réponse en cache à des moments différents. Interrogez le même résolveur public depuis les deux postes pour comparer, puis videz le cache local du poste qui voit encore l'ancienne version.

Que deviennent mes e-mails pendant une propagation ?

Un changement d'enregistrement MX suit les mêmes règles : pendant le délai, certains expéditeurs écrivent encore à l'ancien serveur de messagerie. Gardez-le actif jusqu'à la fin de la transition. En cas d'indisponibilité d'un serveur, les serveurs émetteurs conservent en général les messages et réessaient pendant plusieurs jours.

Faut-il vider le cache de son ordinateur ?

Oui pour vérifier ce que vous voyez, mais cela ne change rien pour les autres visiteurs. Utilisez la commande de votre système, puis fermez complètement le navigateur. Si la valeur est toujours ancienne, c'est le résolveur de votre fournisseur d'accès qui garde la copie.

Pourquoi les outils en ligne de vérification donnent-ils des résultats différents ?

Chacun interroge des résolveurs situés dans des pays différents, qui ont mis la réponse en cache à des moments différents. Un résultat mixte est normal tant que le TTL n'a pas expiré partout. Si les serveurs de noms faisant autorité eux-mêmes répondent différemment, comparez les numéros de série du SOA : le problème vient alors de la zone, pas de la propagation.