# Vérificateur de propagation DNS : estimer votre attente URL: https://notificationharbor.com/fr/tools/verificateur-propagation-dns Type: tool Locale: fr Published: 2026-10-07 Updated: 2026-10-08 --- > Estimez le délai maximal après une modification DNS à partir du TTL et du temps écoulé depuis votre édition. Calcul dans le navigateur, pour enregistrements, DKIM et serveurs de noms. ## Vérificateur de propagation DNS : quand votre modification sera visible Saisissez le TTL et le temps écoulé depuis votre modification. Ce vérificateur de propagation DNS affiche le délai d'attente au pire cas pour une modification d'enregistrement, une nouvelle clé DKIM ou un changement de serveurs de noms. ## Vérificateur de propagation DNS Choisissez le type de modification, saisissez le TTL applicable et le temps écoulé depuis son enregistrement. Le résultat se met à jour pendant la saisie, et rien ne quitte votre navigateur. *[Interactive widget — see the live page for the full experience]* ## Ce que mesure réellement le calculateur ### La propagation, c'est l'expiration du cache Le DNS ne pousse les modifications nulle part. Chaque résolveur conserve la réponse qu'il a récupérée jusqu'à l'expiration du TTL, puis la redemande. Le résolveur le plus lent est celui qui a récupéré l'ancienne réponse juste avant votre modification : le cas le plus défavorable correspond donc à l'ancien TTL. ### Les nouveaux enregistrements ont leur propre horloge Un enregistrement inexistant peut quand même être mis en cache comme absent. Cette réponse négative dure le plus petit des deux : le TTL du SOA ou son champ minimum. Si personne n'a interrogé le nom plus tôt, le nouvel enregistrement est visible immédiatement. ### Les changements de serveurs de noms suivent le registre Changer de serveurs de noms modifie les enregistrements NS de la zone parente, et ce TTL ne se règle pas chez vous. Le calculateur le prend en entrée, deux jours étant la valeur typique pour les grands TLD comme .com. ## Quatre étapes pour raccourcir l'attente 1. **Lire le TTL actuel** — Lancez dig sur l'enregistrement et lisez le nombre dans la section answer. C'est le TTL que votre modification devra dépasser. 2. **L'abaisser à l'avance** — Réglez le TTL sur 300 secondes, puis attendez au moins la durée de l'ancien TTL avant de modifier l'enregistrement. Les résolveurs doivent d'abord expirer la copie de longue durée. 3. **Modifier et noter l'heure** — Enregistrez la modification, notez l'heure, puis saisissez le temps écoulé dans le calculateur ci-dessus. 4. **Vérifier à la source, puis chez un résolveur** — Interrogez d'abord votre serveur de noms faisant autorité, puis un résolveur public. Remontez le TTL une fois que les deux concordent et que la fenêtre est passée. ## Questions fréquentes ### Ce vérificateur de propagation DNS est-il gratuit ? Oui. Pas d'inscription, pas de limite de requêtes. Le calcul est une simple arithmétique sur trois nombres que vous saisissez : il s'exécute dans votre navigateur et rien n'est envoyé à nos serveurs. ### Interroge-t-il des serveurs DNS en direct ? Non. Il ne consulte pas les résolveurs du monde entier pour trouver votre enregistrement. Il calcule le temps maximal pendant lequel une réponse en cache peut survivre, à partir du TTL que vous saisissez. Pour voir ce qu'un résolveur précis renvoie à l'instant, lancez dig sur ce résolveur et comparez le résultat avec la fenêtre affichée ici. ### Pourquoi l'estimation utilise-t-elle l'ancien TTL et non le nouveau ? Les résolveurs mettent en cache la réponse récupérée avant votre modification, avec le TTL qui l'accompagnait. Abaisser le TTL dans la même modification ne change rien pour les résolveurs qui détiennent déjà l'ancienne réponse. Le nouveau TTL ne s'applique qu'aux réponses récupérées après le changement. ### Qu'est-ce que le TTL de cache négatif, et quand s'applique-t-il ? Quand un résolveur demande un nom qui n'a pas d'enregistrement, il peut mettre en cache la réponse « n'existe pas » (RFC 2308). Elle dure le plus petit entre le TTL propre de l'enregistrement SOA et son champ minimum. Cela ne concerne que les résolveurs qui ont interrogé le nom avant que vous ne créiez l'enregistrement, par exemple un sélecteur DKIM testé trop tôt. ### Pourquoi un changement de serveurs de noms prend-il si longtemps ? Les enregistrements NS qui pointent vers vos serveurs de noms sont gérés par le registre, avec un TTL que vous ne contrôlez pas. Pour les grands TLD comme .com, ce TTL est couramment de deux jours. Tant qu'il n'a pas expiré, certains résolveurs continuent d'interroger vos anciens serveurs de noms. ### J'ai dépassé la fenêtre et je vois toujours l'ancienne valeur. Que faire ? Ne blâmez pas les caches tout de suite. Interrogez directement votre serveur de noms faisant autorité et vérifiez qu'il sert la nouvelle valeur. Sinon, la modification est allée dans la mauvaise zone, sur le mauvais nom d'hôte, ou n'a jamais été enregistrée. Si c'est le cas, testez depuis un résolveur que vous n'avez jamais utilisé, et vérifiez la présence d'un cache local sur votre machine ou votre réseau. ### Cela s'applique-t-il aux enregistrements SPF, DKIM et DMARC ? Oui. Ce sont des enregistrements TXT, mis en cache comme les autres. Un serveur destinataire qui a mis en cache votre ancien enregistrement SPF continue de l'évaluer jusqu'à l'expiration du TTL : un envoi juste après une modification peut donc être jugé selon l'ancienne politique. ## Suivez l'infrastructure derrière vos propres envois Cet outil estime une attente. Notification Harbor couvre les envois que vous maîtrisez : préchauffage du domaine, observabilité au niveau de la trace, et SPF, DKIM et DMARC correctement configurés avant le premier envoi en production. *Call to action: Découvrir le fonctionnement de Notification Harbor* ## FAQ ### Ce vérificateur de propagation DNS est-il gratuit ? Oui. Pas d'inscription, pas de limite de requêtes. Le calcul est une simple arithmétique sur trois nombres que vous saisissez : il s'exécute dans votre navigateur et rien n'est envoyé à nos serveurs. ### Interroge-t-il des serveurs DNS en direct ? Non. Il ne consulte pas les résolveurs du monde entier pour trouver votre enregistrement. Il calcule le temps maximal pendant lequel une réponse en cache peut survivre, à partir du TTL que vous saisissez. Pour voir ce qu'un résolveur précis renvoie à l'instant, lancez dig sur ce résolveur et comparez le résultat avec la fenêtre affichée ici. ### Pourquoi l'estimation utilise-t-elle l'ancien TTL et non le nouveau ? Les résolveurs mettent en cache la réponse récupérée avant votre modification, avec le TTL qui l'accompagnait. Abaisser le TTL dans la même modification ne change rien pour les résolveurs qui détiennent déjà l'ancienne réponse. Le nouveau TTL ne s'applique qu'aux réponses récupérées après le changement. ### Qu'est-ce que le TTL de cache négatif, et quand s'applique-t-il ? Quand un résolveur demande un nom qui n'a pas d'enregistrement, il peut mettre en cache la réponse « n'existe pas » (RFC 2308). Elle dure le plus petit entre le TTL propre de l'enregistrement SOA et son champ minimum. Cela ne concerne que les résolveurs qui ont interrogé le nom avant que vous ne créiez l'enregistrement, par exemple un sélecteur DKIM testé trop tôt. ### Pourquoi un changement de serveurs de noms prend-il si longtemps ? Les enregistrements NS qui pointent vers vos serveurs de noms sont gérés par le registre, avec un TTL que vous ne contrôlez pas. Pour les grands TLD comme .com, ce TTL est couramment de deux jours. Tant qu'il n'a pas expiré, certains résolveurs continuent d'interroger vos anciens serveurs de noms. ### J'ai dépassé la fenêtre et je vois toujours l'ancienne valeur. Que faire ? Ne blâmez pas les caches tout de suite. Interrogez directement votre serveur de noms faisant autorité et vérifiez qu'il sert la nouvelle valeur. Sinon, la modification est allée dans la mauvaise zone, sur le mauvais nom d'hôte, ou n'a jamais été enregistrée. Si c'est le cas, testez depuis un résolveur que vous n'avez jamais utilisé, et vérifiez la présence d'un cache local sur votre machine ou votre réseau. ### Cela s'applique-t-il aux enregistrements SPF, DKIM et DMARC ? Oui. Ce sont des enregistrements TXT, mis en cache comme les autres. Un serveur destinataire qui a mis en cache votre ancien enregistrement SPF continue de l'évaluer jusqu'à l'expiration du TTL : un envoi juste après une modification peut donc être jugé selon l'ancienne politique.