La propagation DNS désigne le temps nécessaire pour qu'une modification DNS devienne visible partout. Elle dépend entièrement de la mise en cache régie par le TTL (Time To Live), et non d'un quelconque processus de diffusion ou de synchronisation mondiale. Il n'existe pas de moment unique où une modification « passe en ligne » dans le monde entier : chaque résolveur la prendra en compte à un moment différent, selon ce qu'il a déjà en cache et pour combien de temps.
Comprendre ce mécanisme rend les modifications DNS bien moins mystérieuses. Une fois que vous savez ce qui détermine réellement le délai, vous pouvez planifier vos changements pour qu'ils se déploient de manière prévisible, au lieu de tâtonner en rafraîchissant votre navigateur.
Que signifie réellement « propagation DNS » ?
Le terme ne figure dans aucune spécification DNS officielle : c'est un raccourci utilisé dans le secteur pour désigner le décalage entre la mise à jour d'un enregistrement sur votre serveur de noms faisant autorité et le moment où tous les résolveurs du monde reflètent cette mise à jour. Chaque résolveur qui interroge votre domaine met la réponse en cache, et continue de servir cette réponse en cache jusqu'à l'expiration du délai qu'il s'est fixé.
La « propagation » n'est donc pas quelque chose qui arrive à votre enregistrement. C'est l'effet secondaire naturel de milliers de caches indépendants à travers le monde, qui décident chacun, selon leur propre calendrier, quand reposer la question.
Le véritable facteur : le TTL
Chaque enregistrement DNS comporte une valeur de TTL, exprimée en secondes, définie par la personne qui gère la zone. Le TTL indique à tout résolveur qui met l'enregistrement en cache : « vous pouvez réutiliser cette réponse pendant ce nombre de secondes avant d'être obligé de revérifier auprès du serveur faisant autorité ». Ce comportement est défini dans la RFC 1035, et la RFC 2181 a ensuite précisé que tous les enregistrements d'un même ensemble doivent partager un TTL unique, et que les résolveurs doivent toujours respecter le TTL le plus bas qu'ils ont observé pour cet ensemble.
Quelques valeurs de TTL courantes, et ce qu'elles signifient en pratique :
| TTL (secondes) | Environ | Usage typique |
|---|---|---|
| 300 | 5 minutes | Avant une migration planifiée, ou pour des enregistrements susceptibles de changer souvent |
| 3600 | 1 heure | Une valeur par défaut raisonnable pour la plupart des enregistrements en production |
| 86400 | 24 heures | Enregistrements stables que vous modifiez rarement (certaines entrées MX, NS) |
Un TTL bas signifie une propagation plus rapide, mais davantage de requêtes vers votre DNS faisant autorité. Un TTL élevé signifie moins de requêtes et une meilleure efficacité du cache, mais un déploiement plus lent si vous devez modifier quelque chose en urgence. Si vous ne savez pas quelle valeur est actuellement définie sur un enregistrement, notre outil de recherche DNS vous affichera le TTL réel à côté de la valeur.
Le piège du TTL dans lequel presque tout le monde tombe une fois
Voici ce qui surprend souvent : la réduction d'un TTL ne prend effet qu'après l'expiration du TTL précédent, plus long. Si votre enregistrement A a actuellement un TTL de 24 heures et que vous le passez à 300 secondes, les résolveurs qui ont déjà mis l'enregistrement en cache avec l'ancien TTL continueront d'utiliser cette copie en cache, ainsi que l'ancienne valeur de TTL, pendant jusqu'à 24 heures avant de revérifier et de constater le nouveau TTL, plus court.
La bonne séquence pour toute modification DNS dont le timing compte est donc la suivante :
- Réduisez le TTL de l'enregistrement plusieurs jours avant la modification proprement dite (à environ 300 secondes).
- Attendez que l'ancien TTL ait totalement expiré partout : laissez s'écouler toute la durée de l'ancien TTL, pas celle du nouveau.
- Effectuez la modification réelle (nouvelle IP, nouvelle cible CNAME, peu importe).
- Une fois la modification propagée et stabilisée, remontez le TTL si vous souhaitez à nouveau profiter des avantages du cache.
TipSauter l'étape 1 est la raison la plus fréquente pour laquelle une bascule DNS semble interminable : l'enregistrement que vous venez de modifier n'a jamais été le goulot d'étranglement ; c'était le TTL d'avant votre modification.
Pourquoi un changement de serveurs de noms est plus lent qu'une modification d'enregistrement
Modifier un enregistrement A, CNAME ou MX individuel au sein de votre zone DNS existante est une modification au niveau de l'enregistrement : elle est régie uniquement par le TTL de cet enregistrement. Déléguer un domaine à de tout nouveaux serveurs de noms est différent : il s'agit d'une modification dans la zone parente (le registre), et cet enregistrement de délégation possède son propre TTL, défini par le registre et non par vous.
Comme les intervalles de rafraîchissement du registre et la mise en cache de la zone parente s'ajoutent aux TTL de votre propre zone, les fournisseurs indiquent couramment qu'un changement de délégation de serveurs de noms (NS) peut prendre jusqu'à 24 à 48 heures, même si le chiffre exact varie selon le TLD (domaine de premier niveau) et le registre. Planifiez vos migrations de serveurs de noms en tenant compte de cette fenêtre plus longue, et évitez d'effectuer d'autres modifications DNS urgentes pendant cette période.
Cache négatif : pourquoi corriger un enregistrement manquant prend aussi du temps
Si un résolveur demande un enregistrement qui n'existe pas encore (par exemple, si vous n'avez pas encore créé l'enregistrement A d'un sous-domaine), il met aussi en cache cette réponse négative. C'est ce qu'on appelle le cache négatif, régi par la RFC 2308, qui lie le TTL négatif au champ MINIMUM de l'enregistrement SOA (Start of Authority) de votre zone.
Concrètement : si vous interrogez un sous-domaine avant qu'il n'existe, obtenez une réponse NXDOMAIN, puis créez l'enregistrement cinq minutes plus tard, certains résolveurs peuvent continuer à répondre « n'existe pas » jusqu'à l'expiration de cette entrée de cache négatif. C'est le même mécanisme sous-jacent que la mise en cache TTL classique, simplement appliqué à l'absence plutôt qu'à la présence.
Comment vérifier correctement la propagation DNS
La vérification la plus fiable consiste à interroger directement les serveurs de noms faisant autorité, car ils disposent toujours de la réponse à jour : le délai n'existe que dans les caches des autres, pas dans la source de référence.
dig +trace example.com A
dig @ns1.yourprovider.com example.com A
Vous pouvez aussi utiliser notre outil de recherche DNS pour récupérer l'enregistrement actuel directement depuis le DNS, vérifier le TTL réellement défini et confirmer que la valeur correspond à ce que vous venez de modifier. Si elle ne correspond pas encore, c'est normal : cela signifie simplement que le résolveur que vous interrogez n'a pas refait de requête depuis votre modification, et non que quelque chose est cassé.
Quelques vérifications pratiques à effectuer après toute modification DNS :
- Interrogez plusieurs résolveurs (celui de votre FAI, plus un résolveur public comme Google ou Cloudflare) : ils mettent en cache indépendamment, vous verrez donc des états différents en cours de propagation.
- Vérifiez le TTL en plus de la valeur, pas seulement la valeur : une réponse qui semble obsolète mais dont le TTL restant est faible se corrigera d'elle-même sous peu.
- Si vous gérez des enregistrements MX ou SPF, vérifiez-les avec la recherche MX ou le générateur SPF plutôt que de supposer que les fournisseurs de messagerie ont pris en compte la modification ; consultez notre guide sur la création d'un enregistrement SPF sécurisé pour la syntaxe complète.
WarningNe modifiez pas un enregistrement à répétition dans la précipitation en attendant sa propagation. Chaque modification change ce que les résolveurs verront lors de leur prochaine requête, et si vous êtes au milieu d'une fenêtre de TTL, les changements supplémentaires ne font qu'ajouter de l'incohérence entre les caches, au lieu d'en retirer.
Gérer les TTL et la propagation chez plusieurs fournisseurs
Si vos domaines, votre DNS et vos certificats sont répartis entre plusieurs registraires et clouds, les délais de propagation deviennent plus difficiles à appréhender : vous devez suivre des TTL par défaut différents, des comportements de registraire différents pour les changements NS et des outils différents pour chaque fournisseur. Centraliser la gestion DNS rend la séquence TTL décrite plus haut (réduire, attendre, modifier, remonter) beaucoup plus facile à appliquer de façon cohérente, puisque vous définissez et vérifiez les TTL depuis un seul endroit au lieu de jongler entre plusieurs tableaux de bord. Notre fonctionnalité de gestion DNS vous offre cette vue unique sur tous vos fournisseurs, avec un historique des modifications par enregistrement pour voir exactement ce qui a été défini et quand.
Si vous découvrez encore quels types d'enregistrements sont concernés par le TTL et comment ils interagissent, notre guide complet des types d'enregistrements DNS complète bien celui-ci ; et si vous voulez comprendre plus en profondeur comment un résolveur trouve une réponse, consultez le fonctionnement de la résolution DNS.
La prochaine fois que vous planifiez une modification, commencez par vérifier le TTL actuel (consultez-le ici) et calez votre déploiement dessus au lieu de deviner.
Questions fréquentes
#Combien de temps dure réellement la propagation DNS ?
Cela dépend entièrement du TTL défini sur l'enregistrement avant votre modification : un enregistrement avec un TTL de 5 minutes se stabilise généralement en quelques minutes, tandis qu'un enregistrement avec un TTL de 24 heures peut nécessiter jusqu'à une journée entière pour que tous les résolveurs refassent leur requête. Les changements de délégation de serveurs de noms au niveau du registre sont généralement plus lents, souvent annoncés jusqu'à 24 à 48 heures.
#Peut-on accélérer la propagation DNS ?
Vous ne pouvez pas forcer les autres résolveurs à vider leur cache plus tôt, mais vous pouvez réduire le TTL de l'enregistrement bien avant d'effectuer la modification, afin que l'ancien TTL, plus long, ait déjà expiré au moment où vous la faites. C'est la technique standard pour minimiser le délai visible lors d'une bascule planifiée.
#Vider mon cache DNS local règle-t-il les délais de propagation ?
Cela ne règle que les délais dus au cache de votre propre machine ou de votre routeur : cela n'a aucun effet sur le résolveur de votre FAI, sur les résolveurs publics comme Google ou Cloudflare, ni sur tout autre résolveur ayant mis l'enregistrement en cache de son côté. La propagation complète dépend toujours de l'expiration de chacun de ces caches selon son propre TTL.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
