Propagation DNS : combien de temps et comment la suivre

« Il faut compter 24 à 72 heures. » C’est la réponse que donnent la plupart des hébergeurs quand on leur demande combien de temps dure une propagation DNS, et elle est fausse dans la quasi-totalité des cas. Le délai réel n’est pas une constante : c’est une valeur que vous avez choisie, souvent sans le savoir, et que vous pouvez ramener à quelques minutes. Voici comment elle se calcule, comment on la contrôle avant une migration, et comment on la vérifie.

Rien ne se propage, en réalité

Le mot « propagation » décrit mal ce qui se passe, et c’est la source de la confusion. Aucune information ne voyage de serveur en serveur à travers le monde. Vos enregistrements sont modifiés instantanément sur vos serveurs de noms, et ils y sont exacts dès la seconde suivante.

Ce qui prend du temps, c’est l’oubli. Entre un visiteur et vos serveurs de noms s’intercalent des résolveurs, celui de son fournisseur d’accès, celui de son entreprise, celui de son système, celui de son navigateur. Chacun conserve la réponse précédente en mémoire et continue de la servir sans rien redemander. Tant que cette copie n’a pas expiré, le visiteur atteint l’ancienne adresse, et il n’y a rien à faire pour l’en empêcher.

La propagation DNS n’est donc pas une diffusion. C’est l’expiration progressive de copies périmées, et sa durée est écrite dans vos enregistrements.

Le TTL est la seule valeur qui compte

Chaque enregistrement DNS porte un TTL, pour Time To Live, exprimé en secondes. Il indique aux résolveurs combien de temps ils ont le droit de conserver la réponse avant de la redemander. C’est exactement la durée de votre propagation, ni plus ni moins.

TTL	En clair	Durée maximale de la propagation
300	5 minutes	5 minutes
3600	1 heure	1 heure
14400	4 heures	4 heures
86400	24 heures	24 heures

Un TTL de 3 600 secondes signifie qu’au pire, une heure après votre modification, tout résolveur ayant respecté la consigne servira la nouvelle valeur. Pas 72 heures. Une heure.

D’où vient alors le chiffre de 48 heures

Il n’est pas inventé, mais il ne s’applique qu’à un seul cas : le changement de serveurs de noms, c’est-à-dire quand vous confiez votre domaine à un autre hébergeur DNS. Cette information-là n’est pas publiée par vous, elle est publiée par le registre de l’extension, et c’est lui qui en fixe le TTL.

La zone .com délègue avec un TTL de 172 800 secondes, soit très exactement 48 heures, et la plupart des grandes extensions retiennent un ordre de grandeur comparable. Voilà le fameux délai. Il ne concerne pas la modification d’un enregistrement A, MX ou CNAME, qui reste gouvernée par votre propre TTL.

• Changer une adresse IP, un enregistrement MX, un CNAME : votre TTL, que vous maîtrisez.
• Changer de serveurs de noms : le TTL du registre, que vous ne maîtrisez pas.

La manœuvre qui ramène la coupure à cinq minutes

Elle tient en trois temps, et c’est le seul moyen d’avoir une migration sans trou. L’erreur classique est d’abaisser le TTL le jour du changement : c’est trop tard, puisque les résolveurs détiennent encore l’ancienne valeur avec l’ancien TTL.

1. La veille ou l’avant-veille, abaissez le TTL de l’enregistrement concerné à 300 secondes. Ne touchez à rien d’autre.
2. Attendez l’ancien TTL en entier. Si votre TTL était de 24 heures, attendez 24 heures. C’est le temps qu’il faut pour que la nouvelle consigne remplace l’ancienne partout.
3. Faites la bascule. La modification sera visible partout en cinq minutes. Remontez le TTL à sa valeur habituelle une fois la migration validée.

Un TTL bas en permanence augmente le nombre de requêtes vers vos serveurs de noms et ajoute quelques millisecondes à la première visite. C’est négligeable pour un site ordinaire, et c’est le même arbitrage que celui décrit dans notre article sur l’optimisation des performances d’un site.

Vérifier où en est réellement la propagation

Interroger votre site dans un navigateur ne prouve rien : vous testez votre propre cache. Il faut interroger les résolveurs un par un.

dig +noall +answer exemple.fr A            # la reponse de votre resolveur, avec le TTL restant
dig exemple.fr A @8.8.8.8                  # ce que sert Google Public DNS
dig exemple.fr A @1.1.1.1                  # ce que sert Cloudflare
dig +trace exemple.fr A                    # le chemin complet, depuis la racine

Le nombre affiché à côté de l’enregistrement est le TTL restant : il décompte. S’il indique 1 800 alors que votre TTL est de 3 600, la copie a une demi-heure et expirera dans trente minutes. C’est l’information la plus utile de tout le diagnostic, et elle n’apparaît sur aucun vérificateur en ligne.

Sur Windows, ipconfig /flushdns vide le cache local. Sur macOS, sudo dscacheutil -flushcache. Cela ne change rien pour vos visiteurs, dont vous ne contrôlez pas la machine, mais cela vous évite de conclure à tort que la bascule a échoué.

Pourquoi les vérificateurs en ligne vous alarment pour rien

Les outils qui affichent une carte du monde couverte de croix rouges et de coches vertes sont utiles, mais ils sont systématiquement mal lus. Une croix rouge ne signifie pas que la propagation a échoué quelque part.

Ces services interrogent une trentaine de résolveurs publics répartis sur plusieurs continents. Chacun a mis en cache votre enregistrement à un moment différent, donc chacun l’expirera à un moment différent. À mi-parcours du TTL, il est parfaitement normal que la moitié affiche l’ancienne valeur et l’autre la nouvelle. Ce n’est pas une anomalie, c’est la mécanique elle-même qui s’affiche.

Le seul cas qui doit inquiéter est celui où une croix rouge persiste au-delà du TTL que vous aviez fixé. Là, ce n’est plus du cache : soit le résolveur en question ignore les TTL courts et applique un minimum à lui, ce que certains font, soit votre modification n’a pas été enregistrée là où vous croyez l’avoir faite. Vérifiez alors directement vos serveurs de noms faisant autorité, que dig +trace vous désigne.

Ce que la propagation n’explique pas

La réserve est importante, parce que le DNS sert d’explication commode à des pannes qui n’ont rien à voir. Trois symptômes sont régulièrement mis sur son compte à tort.

• Un certificat invalide après la bascule. Le nom résout correctement, mais le nouveau serveur n’a pas encore de certificat pour ce domaine. C’est un problème de certificat, traité dans notre article sur la sécurité d’un serveur.
• Un site qui alterne entre ancienne et nouvelle version. Ce n’est pas une propagation en cours, c’est le comportement normal de deux serveurs vivants pendant la fenêtre d’expiration. Gardez l’ancien en ligne jusqu’à la fin du TTL.
• Une modification WHOIS. Changer vos coordonnées de propriétaire n’a aucun effet sur la résolution du domaine. Les deux sujets sont indépendants, et les confondre fait attendre 72 heures pour rien.

Si le domaine ne résout nulle part, le problème n’est pas une propagation mais une configuration absente ou une panne. La distinction entre les deux se fait avec les mêmes outils que ceux présentés dans notre article sur les bases du fonctionnement d’un réseau, et la démarche de diagnostic est décrite dans notre méthode pour diagnostiquer une coupure réseau.

Enfin, si vous êtes en train de choisir le domaine lui-même plutôt que de le migrer, les critères qui comptent sont réunis dans notre article sur le choix d’un nom de domaine d’entreprise.

Questions fréquentes sur la propagation DNS

Combien de temps faut-il pour que le DNS se propage ?

Exactement la durée du TTL de l’enregistrement modifié. Avec un TTL de 3 600 secondes, une heure au maximum. Le délai de 24 à 72 heures souvent annoncé ne s’applique qu’au changement de serveurs de noms, dont le TTL est fixé par le registre de l’extension.

Pourquoi un changement de serveurs de noms prend-il 48 heures ?

Parce que cette information est publiée par le registre de l’extension et non par vous. La zone .com délègue avec un TTL de 172 800 secondes, soit 48 heures. Vous ne pouvez pas abaisser cette valeur.

Comment puis-je tester la propagation de mon DNS ?

Avec la commande dig en interrogeant plusieurs résolveurs publics, par exemple dig exemple.fr A @8.8.8.8 puis @1.1.1.1. Le nombre affiché à côté de l’enregistrement est le TTL restant avant expiration de la copie en cache.

Comment accélérer la propagation DNS ?

On ne l’accélère pas après coup, on la prépare. Abaissez le TTL à 300 secondes au moins un ancien TTL avant la migration, puis faites la bascule. La modification sera alors visible partout en cinq minutes.

Vider le cache DNS de mon ordinateur accélère-t-il la propagation ?

Uniquement pour vous. ipconfig /flushdns sous Windows et dscacheutil -flushcache sous macOS vident votre cache local, mais n’ont aucun effet sur les résolveurs de vos visiteurs.