Résumé

Ce vérificateur de propagation DNS estime combien de temps une modification DNS peut rester invisible pour certains résolveurs. La propagation, c'est l'expiration du cache : un résolveur garde l'ancienne réponse jusqu'à l'expiration de son TTL, donc le cas le plus défavorable correspond à l'ancien TTL. Les nouveaux enregistrements peuvent être mis en cache comme absents pendant le TTL négatif du SOA, et les changements de serveurs de noms suivent le TTL NS du registre. Indiquez le type de modification, le TTL et le temps écoulé depuis votre édition pour voir le délai restant. Le calcul s'exécute dans votre navigateur et n'interroge pas le DNS en direct.

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érifier votre délai d'attente

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.

Le TTL que l’enregistrement avait avant votre modification, pas le nouveau.

Fonctionnement

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.

Avant une modification DNS d'email

Quatre étapes pour raccourcir l'attente

Voici l'ordre que nous suivons pour les modifications SPF, DKIM, DMARC et MX sur un domaine d'envoi.

  1. 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. 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. 3

    Modifier et noter l'heure

    Enregistrez la modification, notez l'heure, puis saisissez le temps écoulé dans le calculateur ci-dessus.

  4. 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.

Découvrir le fonctionnement de Notification Harbor
notificationharbor
Démarrer gratuitement