Le moment le plus coûteux d’une bascule DNS, c’est l’écart entre « on a mis à jour l’enregistrement » et « le monde est d’accord ». Tant que cinq résolveurs majeurs ne retournent pas la même réponse, vous ne pouvez pas honnêtement dire au client que le changement est en ligne, et vous ne devriez pas basculer le changement dépendant suivant. Le DNS Propagation Checker de PortJar existe pour compresser cette étape de confirmation, qui prenait avant un onglet plein de vérificateurs régionaux, en une seule requête.
Ce que l’outil fait
Il déclenche la même requête DNS en parallèle contre Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9, NextDNS et OpenDNS via DNS-over-HTTPS, et aligne les réponses côte à côte. Si les cinq sont d’accord, l’enregistrement s’est effectivement propagé — ces résolveurs servent l’essentiel du trafic réel. Si l’un ou l’autre diverge, le changement est encore en cours de diffusion et l’ancien enregistrement est encore servi quelque part.
La forme à cinq résolveurs est délibérée. Les résolveurs anycast comme Google et Cloudflare masquent les variations de cache régional qu’une vérification monorégionale raterait. Regarder cinq fournisseurs indépendants à la fois donne un signal bien meilleur que de cogner un seul résolveur depuis vingt emplacements.
Comment l’utiliser
Ouvrez portjar.com/tools/dns-propagation, entrez le domaine, et choisissez le type d’enregistrement que vous avez effectivement modifié — A, MX, NS, TXT, peu importe. Lancez la vérification tout de suite après avoir publié le changement, puis toutes les quelques minutes jusqu’à ce que les cinq colonnes correspondent à la valeur attendue.
Partagez l’URL avec le client quand il demande si le changement est passé. La réponse qu’il voit est la même que vous, et elle se met à jour à chaque rechargement de page.
Quand vous y recourriez
- Tout de suite après une bascule informée par le TTL — vous avez baissé le TTL à 300 la veille, publié le nouvel enregistrement
Aà la fenêtre de bascule, et vous devez confirmer la propagation avant de mettre l’ancienne origine hors service. Lisez la référence TTL de PortJar pour comprendre pourquoi le TTL précédent gouverne la durée de vie des retardataires. - Un changement de délégation des serveurs de noms chez le registraire (enregistrements
NS) — ceux-là se propagent typiquement plus lentement que les enregistrements de zone et un seul résolveur peut traîner des heures. - Un nouveau
MXsur un domaine migré d’un fournisseur de courriel à un autre — tant que la propagation n’est pas complète, le courriel se divise entre les deux destinations. - Un changement
SPFouDMARCoù la politique ancienne en cache chez le destinataire rebondit le courriel que vous venez d’autoriser ; vérifier la propagation vous dit s’il faut attendre ou relancer le destinataire. - Un échec d’émission de certificat qui exige un nouveau TXT
_acme-challenge— le serveur ACME doit voir le nouveau TXT avant que le défi ne se valide, et un résolveur lent peut bloquer le renouvellement.
Quoi faire de la sortie
Les cinq résolveurs retournant la même valeur, c’est l’objectif. Traitez ça comme « propagé » et passez à autre chose.
Un résolveur qui sert encore l’ancienne valeur pendant que les autres sont à jour signifie presque toujours que ce résolveur a un TTL de cache qui décompte. Attendez le TTL de l’enregistrement précédent et revérifiez. Si le retardataire persiste au-delà de cette fenêtre, il y a généralement une couche de cache en amont (un résolveur d’entreprise, une zone Cloudflare avec des données obsolètes, un récurseur de FAI) et la bonne manœuvre est d’interroger le retardataire depuis son propre point de diagnostic, pas de continuer à rafraîchir PortJar.
Une réponse vide de chaque résolveur après qu’un changement aurait dû apparaître veut généralement dire que l’enregistrement a été publié avec le mauvais nom — apex vs sous-domaine, point final manquant, mauvais type d’enregistrement. Revenez à DNS Lookup et confirmez que l’enregistrement existe bien où vous l’attendez.
Méfiez-vous du faux positif « propagé vite ». Si vous vérifiez trente secondes après la publication et que les cinq résolveurs sont d’accord sur la nouvelle valeur, demandez-vous si vous regardez bien la bonne zone — parfois l’enregistrement était déjà publié et vous avez sauvegardé une valeur inchangée.
Stack Harbor lance des vérifications de propagation à chaque frontière de bascule dans le cadre de la gestion de déploiement — c’est l’assurance la moins chère contre l’annonce « on est basculé » alors qu’un quart des utilisateurs frappe encore l’ancienne origine.