Vérificateur de propagation DNS
Demandez à quatre résolveurs publics où pointe un domaine — Google, Cloudflare, Quad9 et OpenDNS — et voyez s'ils sont d'accord. Une question, quatre réponses, depuis le serveur de sysosx : la façon honnête la plus rapide de savoir si un changement DNS s'est réellement propagé.
Vous préférez que ce soit surveillé automatiquement ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Ce qu’est vraiment la propagation
Il n’existe aucun événement de propagation. Quand vous modifiez un enregistrement DNS, rien ne voyage nulle part : le serveur de noms faisant autorité se met simplement à répondre différemment, et chaque résolveur du monde continue de servir ce qu’il a récupéré en dernier jusqu’à l’expiration du TTL de cette réponse. Un résolveur qui a demandé cinq minutes avant votre modification sert l’ancienne valeur pendant le reste de son TTL ; un résolveur qui demande pour la première fois après votre modification obtient immédiatement la nouvelle valeur. La « propagation » n’est que la lente convergence de milliers de caches indépendants, chacun avec sa propre horloge — c’est pourquoi elle n’a pas d’heure de fin, seulement une fenêtre limitée par le TTL, et pourquoi la question honnête n’est jamais « est-ce propagé ? », mais « les résolveurs qui comptent sont-ils déjà d’accord ? ».
Cette page répond à cette question pour les quatre résolveurs que la majeure partie d’internet utilise réellement. Google, Cloudflare, Quad9 et OpenDNS sont interrogés en parallèle, depuis le serveur de sysosx, sur les enregistrements A et AAAA du domaine, et le tableau montre ce que chacun a dit, avec le TTL le plus bas observé. Quand les quatre sont d’accord, le changement s’est propagé aussi loin qu’il en a pratiquement besoin. Quand ils diffèrent, la colonne TTL vous dit combien de temps le désaccord dure : attendez qu’il passe, puis revérifiez. Abaisser le TTL d’un enregistrement à quelques minutes un jour ou deux avant une migration planifiée est l’astuce de propagation la plus efficace qui soit — elle raccourcit la mémoire de chaque cache avant le changement, au lieu de lutter contre elle après.
Comment lire le tableau
Chaque ligne est un résolveur. La colonne A est l’adresse IPv4 qu’il renvoie, AAAA l’adresse IPv6 si le domaine en a une, et le TTL est la durée de vie la plus basse parmi les réponses — le nombre de secondes pendant lesquelles ce résolveur continuera de croire sa réponse avant de redemander. Un résolveur marqué « timeout » n’a pas répondu à temps ; c’est une affirmation sur le résolveur, pas sur votre enregistrement, et les autres lignes restent valables. Un résultat « does not exist » signifie que chaque résolveur ayant répondu s’accorde à dire que le nom n’est pas enregistré du tout — vérifiez l’orthographe avant toute autre chose. Et quand la bannière dit que les résolveurs diffèrent, résistez à l’envie de « réparer » quoi que ce soit : revérifier chaque minute n’accélère le cache de personne, et modifier à nouveau l’enregistrement ne fait que redémarrer chaque TTL que vous attendiez.
Outils associés : la consultation DNS pour l’ensemble complet des enregistrements d’un résolveur quand un seul enregistrement doit être inspecté, la chaîne de statuts HTTP quand l’adresse est bonne mais le chemin de redirection est mauvais, et le bilan de santé du site web pour le tableau complet — accessibilité, certificat, expiration et enregistrements ensemble.
Lecture complémentaire : pourquoi un site semble différent selon l’endroit — chaînes de redirection, propagation DNS et caches intermédiaires, et comment savoir lequel vous mord.
Questions fréquentes
Est-ce une vérification de propagation mondiale ?
Non — et aucun outil ne l’est honnêtement. Cette page pose la même question à quatre grands résolveurs publics (Google, Cloudflare, Quad9 et OpenDNS) depuis le serveur de sysosx et montre s’ils sont d’accord. Quatre résolveurs d’accord sont une preuve solide qu’un changement s’est propagé ; quatre en désaccord sont le signal d’attendre le TTL. Personne ne peut interroger chaque résolveur de la planète, et tout outil qui prétend le faire vend une carte, pas une mesure.
Pourquoi les résolveurs diffèrent-ils après que je modifie un enregistrement ?
Parce que rien ne pousse un changement nulle part. Chaque résolveur met en cache ce qu’il a récupéré en dernier, exactement pour la durée que dit le TTL de l’enregistrement, et se rafraîchit selon son propre calendrier. Un résolveur qui a récupéré l’ancienne valeur cinq minutes avant votre modification continue de la servir jusqu’à l’expiration de ce TTL. Le désaccord juste après une modification est l’état normal, pas une erreur — la colonne TTL vous dit combien de temps il dure.
Que signifie « pas de réponse » d’un résolveur ?
Cela dépend du type. NXDOMAIN signifie que ce résolveur affirme avec autorité que le nom n’existe pas — généralement une faute de frappe, ou un enregistrement supprimé plutôt que modifié. Une réponse vide sans erreur signifie que le nom existe mais ne détient aucun enregistrement A ou AAAA (un domaine réservé au courrier, par exemple). Un délai dépassé signifie que ce résolveur n’a pas répondu à temps ; cela ne dit rien sur l’enregistrement lui-même, et les réponses des trois autres résolveurs restent valables.
En quoi est-ce différent de la consultation DNS ?
La consultation DNS montre l’ensemble complet des enregistrements d’un résolveur — chaque type, avec les TTL —, ce que vous voulez quand vous déboguez un seul enregistrement. Cette page montre une question (où pointe ce nom ?) sur quatre résolveurs, ce que vous voulez quand vous demandez si un changement s’est propagé. Utilisez la consultation pour inspecter un enregistrement, cette page pour juger la propagation.
Pourquoi y a-t-il une limite de débit, et pourquoi le cache ne dure-t-il que dix minutes ?
Chaque vérification effectue huit requêtes en direct (A et AAAA auprès de quatre résolveurs). Les vérifications fraîches sont limitées par visiteur (environ vingt par heure, avec une petite marge de rafale) pour rester poli, et les résultats sont mis en cache dix minutes plutôt qu’une heure — parce qu’une vérification de propagation dont la réponse a une heure va à l’encontre de son propre but. Un résultat en cache est étiqueté comme tel.