La propagation DNS, c’est le délai entre la modification d’un enregistrement DNS et le moment où tout le monde voit la nouvelle valeur. En réalité, rien n’est diffusé : les résolveurs du monde entier continuent de servir la copie qu’ils ont mise en cache jusqu’à l’expiration de son TTL (time to live), puis reposent la question. La plupart des modifications d’enregistrements sont visibles partout dans la limite du TTL de l’ancien enregistrement, souvent de quelques minutes à une heure. Un changement de serveurs de noms chez le registrar peut prendre jusqu’à deux jours. Pour savoir où en est un changement, interrogez les serveurs de noms du domaine sur ce qu’ils publient, puis demandez à quelques résolveurs publics ce qu’ils ont encore en cache.
Ce qui se passe quand vous modifiez un enregistrement
Le navigateur d’un visiteur n’interroge pas directement votre fournisseur DNS. La requête traverse plusieurs caches, et chacun peut répondre de mémoire :
Le navigateur conserve les réponses récentes pendant un court moment.
Le système d’exploitation dispose de son propre cache de résolution.
Un résolveur récursif chez le FAI, sur le réseau de l’entreprise ou dans un service public comme 1.1.1.1 ou 8.8.8.8 met chaque réponse en cache aussi longtemps que son TTL le permet.
Les serveurs de noms faisant autorité pour votre domaine détiennent les vrais enregistrements. Au début, ils sont les seuls à connaître votre modification.
Lorsque vous enregistrez une modification chez votre fournisseur DNS, les serveurs de noms faisant autorité la servent généralement en quelques secondes ou minutes. Chaque cache situé en aval conserve l’ancienne réponse jusqu’à l’expiration de sa copie. Deux visiteurs sur des réseaux différents peuvent donc voir des serveurs différents pendant un moment : c’est normal, pas une erreur. Le TTL se règle par enregistrement, en secondes, et c’est vous qui le fixez ; l’entrée du glossaire sur la propagation DNS en donne la version courte.
Combien de temps prend la propagation DNS
Enregistrements ordinaires : l’ancien TTL
Pour un enregistrement A, AAAA, CNAME, MX ou TXT, l’attente la plus longue correspond au TTL qu’avait l’ancien enregistrement lorsque les résolveurs l’ont mis en cache. Un enregistrement avec un TTL de 3600 peut être servi depuis le cache jusqu’à une heure après sa modification. Baisser le TTL au moment même du changement n’aide pas : les résolveurs qui détiennent déjà l’ancienne copie la gardent pendant l’ancien TTL.
Changement de serveurs de noms : la zone parente
Transférer un domaine vers un autre fournisseur DNS implique de modifier ses enregistrements NS chez le registrar. Ils sont publiés dans la zone parente, par exemple .com, et c’est la zone parente qui fixe leur TTL, pas vous. Vous pouvez le constater en interrogeant directement un serveur .com :
dig +norecurse @a.gtld-servers.net example.com NS
La réponse liste les serveurs de noms avec un TTL de 172800 secondes, soit 48 heures. C’est de là que vient le conseil « jusqu’à 48 heures ». Pendant ce temps, certains résolveurs interrogent l’ancien fournisseur et d’autres le nouveau : les deux doivent donc servir les mêmes enregistrements jusqu’à ce que le changement soit stabilisé.
Nouveaux noms : le cache négatif
Si quelqu’un a interrogé un nom avant qu’il n’existe, par exemple un nouveau sous-domaine testé trop tôt, les résolveurs peuvent aussi mettre en cache la réponse « ce nom n’existe pas ». La RFC 2308 fixe la durée : la plus petite valeur entre le champ minimum de l’enregistrement SOA et le TTL de l’enregistrement SOA lui-même. Voilà pourquoi un tout nouveau sous-domaine peut afficher DNS_PROBE_FINISHED_NXDOMAIN pendant un moment sur un réseau et fonctionner sur un autre.
Les applications qui gardent les adresses
Un programme qui tourne longtemps, comme un serveur d’applications ou un proxy, peut résoudre un nom d’hôte une seule fois au démarrage et conserver l’adresse jusqu’à son redémarrage, quel que soit le TTL. Si un service continue de parler à l’ancien serveur alors que tout le reste a basculé, redémarrez-le avant de soupçonner le DNS.
Comment vérifier la propagation DNS
Partez de la source et avancez vers l’extérieur. Confirmez d’abord que le changement est publié, puis voyez quels caches ont encore l’ancienne réponse.
1. Trouvez les serveurs de noms faisant autorité
dig NS example.com +short
Si ce ne sont pas les serveurs de noms du fournisseur chez qui vous avez fait la modification, vous avez modifié la mauvaise zone. C’est une raison fréquente pour laquelle un changement « ne se propage jamais ».
2. Interrogez chaque serveur de noms directement
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Répétez l’opération pour chaque serveur de noms de la liste. Tous doivent renvoyer la nouvelle valeur et le même numéro de série SOA, le troisième champ de la réponse SOA. Un serveur avec un numéro de série plus ancien n’a pas encore reçu la mise à jour ; c’est une propagation interne à votre fournisseur, qui se règle généralement en quelques minutes.
3. Interrogez des résolveurs publics
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Sans +short, dig affiche le TTL de chaque réponse. Venant d’un résolveur, ce nombre correspond au temps restant sur sa copie en cache : une ancienne valeur à laquelle il reste 1200 secondes sera remplacée d’ici 20 minutes. Sous Windows, nslookup -type=A example.com 1.1.1.1 interroge un résolveur précis, sans le TTL. Notre outil gratuit de recherche DNS affiche les réponses et les TTL de n’importe quel type d’enregistrement depuis le résolveur de notre serveur à Stockholm, sans rien installer.
4. Suivez la délégation après un changement de serveurs de noms
dig +trace example.com
+trace part de la racine et suit les renvois jusqu’à vos serveurs de noms, en ignorant les caches en chemin. Si la trace aboutit chez le nouveau fournisseur, le changement chez le registrar est en ligne, et il ne reste plus qu’à attendre que les caches se mettent à jour.
Planifier un changement pour que la propagation ne pose pas problème
Impossible d’accélérer la propagation après un changement, mais vous pouvez la raccourcir avant de commencer. Pour une migration vers un nouveau serveur :
QuandÉtapeAu moins un ancien TTL avantBaissez le TTL de l’enregistrement, par exemple de 3600 à 300 secondes.Avant le changementMettez en place le nouveau serveur et testez-le, par exemple avec une entrée dans le fichier hosts ou curl –resolve.Le changementFaites pointer l’enregistrement vers le nouveau serveur et vérifiez la réponse faisant autorité.Pendant la propagationLaissez l’ancien serveur tourner et servir le même contenu. Certains visiteurs y arrivent encore.Environ un jour plus tardRemontez le TTL et éteignez l’ancien serveur.
Pour un changement de serveurs de noms, copiez d’abord tous les enregistrements chez le nouveau fournisseur et comparez les deux zones enregistrement par enregistrement, MX et TXT compris. Un enregistrement TXT oublié casse l’authentification des e-mails ; le vérificateur SPF, DKIM et DMARC indique si elle passe toujours. Si le domaine utilise DNSSEC, suivez les étapes du nouveau fournisseur pour l’enregistrement DS chez le registrar : un enregistrement DS qui ne correspond pas aux nouveaux serveurs de noms fait répondre SERVFAIL aux résolveurs qui valident.
Vider les caches que vous contrôlez
Vous pouvez vider vos propres caches pour voir plus tôt la nouvelle valeur, ce qui aide pendant les tests. Cela ne change rien pour vos visiteurs.
macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows : ipconfig /flushdns
Chrome : ouvrez chrome://net-internals/#dns et videz le cache des hôtes.
Résolveurs publics : Cloudflare et Google permettent de purger un nom de leurs caches, sur la page de purge de 1.1.1.1 et la page de vidage de Google Public DNS.
Le résolveur de votre FAI et ceux de vos visiteurs ne peuvent pas être vidés de l’extérieur. Ils expirent à leur propre rythme.
Quand ce n’est pas la propagation
Si les serveurs de noms faisant autorité renvoient encore l’ancienne valeur, attendre ne servira à rien. Cherchez plutôt l’une de ces causes :
La mauvaise zone ou le mauvais fournisseur. L’enregistrement a été modifié chez un fournisseur que le domaine n’utilise plus.
Le mauvais nom. L’apex (example.com) et www.example.com sont des enregistrements distincts.
Un proxy en frontal. Lorsqu’un CDN ou un proxy est activé pour l’enregistrement, le DNS public renvoie les adresses du proxy, pas celles de votre serveur, et c’est voulu.
Un enregistrement jamais sauvegardé, ou une faute de frappe dans la valeur. Comparez ce que vous voyez dans le panneau du fournisseur avec la réponse de dig.
L’entrée types d’enregistrements DNS explique le rôle de chaque enregistrement, et la checklist site en panne couvre les étapes après le DNS.
Savoir quand un enregistrement change avec Uptimecheck
La propagation, c’est le changement DNS prévu. Celui qui n’est pas prévu, une faute de frappe pendant une migration ou un compte registrar piraté, est celui qui mérite une alerte. La surveillance DNS d’Uptimecheck surveille les enregistrements A, AAAA, CNAME, MX, NS, SOA, TXT et CAA :
Elle interroge directement les serveurs de noms faisant autorité du domaine : un changement apparaît donc au contrôle suivant, sans cache de résolveur entre les deux. Lorsque les serveurs de noms donnent des réponses différentes, la page du moniteur l’indique.
Un nouveau jeu d’enregistrements déclenche une alerte dès que deux contrôles consécutifs l’ont constaté, avec l’ancienne et la nouvelle valeur, et il est conservé dans l’historique de l’enregistrement.
Saisissez les valeurs attendues : le contrôle échoue chaque fois que les enregistrements publiés ne correspondent pas, ce qui confirme aussi qu’un changement prévu est bien en ligne.
Les contrôles peuvent tourner jusqu’à toutes les minutes. Start inclut 10 moniteurs DNS, Professional 25 et Business 150.
Associez-la à des contrôles de disponibilité sur le site lui-même et à la surveillance de l’expiration du domaine. Pour en configurer une, voyez comment configurer la surveillance DNS, et lisez comment détecter des enregistrements DNS détournés pour connaître les signaux d’alerte.
Sachez à l’instant même où vos enregistrements changent. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.