Vérificateur DNS

Exécutez une recherche de référence avant tout changement de nameserver, transfert registrar ou bascule de fournisseur mail. Capturez A, AAAA, MX, TXT (SPF, DKIM, DMARC), NS et SOA dans un ticket de changement. Après cutover, relancez la même recherche et comparez les réponses ligne par ligne. Le serial SOA s'incrémente chez beaucoup de fournisseurs quand le fichier de zone change — notez-le si le support affirme que « la propagation est terminée » alors que votre portable montre encore d'anciennes routes mail.

Utilisez le DNS Checker lors de l'onboarding d'un SaaS demandant un TXT de vérification, pour déboguer la délivrabilité après rotation SPF ou DKIM, pour confirmer CAA avant émission de certificats, ou quand un CDN orange-cloud modifie des réponses A anycast. Vérifier dns records online est plus rapide qu'installer bind-utils sur des portables verrouillés et plus complet que ping ou nslookup — qui ne montrent jamais MX, TXT ou CAA dans une vue structurée.

Associez une recherche complète à WHOIS quand la délégation elle-même est suspecte : si les nameservers chez le registrar ne correspondent pas aux NS renvoyés publiquement, vous éditez peut-être un panneau DNS inactif pendant que le monde interroge encore l'ancien hôte. Pour des traces mono-type (MX seul, TXT seul, NS seul), l'outil DIG sur le même site renvoie des sections answer au format resolver à coller dans les fils support sans reformatage.

Si le DNS Checker affiche des valeurs différentes de votre panneau de contrôle, comparez d'abord les NS. Vous êtes peut-être dans un éditeur de zone enfant alors que l'apex délègue ailleurs. Interrogez les NS autoritaires avec DIG @ns1.example.com quand les caches récursifs mentent — notre checker utilise un chemin de résolution configuré reflétant ce que voient la plupart des visiteurs, pas forcément le fichier autoritatif quelques secondes après Save.

Le TTL détermine combien de temps persistent les anciennes réponses. Un enregistrement en cache 86400 secondes peut mettre jusqu'à vingt-quatre heures à disparaître de chaque resolver mondial même après correction. Baissez le TTL sur des enregistrements stables vingt-quatre à quarante-huit heures avant un changement planifié, vérifiez le TTL plus bas avec le DNS Checker, appliquez les nouvelles données, puis remontez le TTL après stabilisation.

Des enregistrements SPF TXT dupliqués sur le même owner name invalident SPF entièrement — fusionnez les includes en une chaîne. CNAME sur un label portant aussi MX ou TXT est invalide selon les règles DNS et produit un comportement resolver imprévisible. DMARC sans SPF ou DKIM alignés signale des échecs sans les corriger ; traitez DMARC comme couche de politique au-dessus d'enregistrements d'auth fonctionnels, pas comme substitut.

L'anycast géographique et les noms proxied CDN peuvent renvoyer des réponses A ou AAAA différentes selon la localisation du resolver. C'est attendu, pas un bug de propagation. Lors du débogage du routage origin, comparez grey-cloud vs orange-cloud dans votre panneau DNS et relancez le DNS Checker depuis le même chemin de résolution après chaque bascule.

Le mail entrant dépend des priorités MX et des noms d'hôtes d'échange joignables. La réputation sortante dépend des TXT SPF, DKIM et DMARC à des noms prévisibles. Le DNS Checker regroupe MX et TXT dans une réponse pour confirmer que mail.example.com résout, qu'un seul SPF existe à l'apex, que votre label selector._domainkey publie une clé publique actuelle et que _dmarc.example.com indique la politique voulue (none, quarantine ou reject).

Après Google Workspace, Microsoft 365 ou tout onboarding SMTP relay, vérifiez les quatre familles avant l'envoi massif. Un MX fonctionnel n'implique pas un SPF correct — comparez les IP SMTP sortantes à la chaîne include SPF et à la doc du fournisseur. Copiez le TXT concaténé exact du checker plutôt que de retaper depuis des PDF ; les chaînes DKIM découpées dans le panneau se concatènent dans les réponses DNS.

Quand les en-têtes Authentication-Results montrent spf=fail ou dkim=fail, relancez une requête TXT live avec le DNS Checker, corrigez la zone, notez le TTL et attendez l'expiration du cache avant retest. Utilisez le Blacklist Checker sur les IP d'envoi si des deferrals persistent après une auth DNS propre — les correctifs DNS sont des prérequis de délivrabilité mais ne remplacent pas le travail de réputation IP.

Cet outil affiche les enregistrements DNS renvoyés par notre resolver maintenant — une recherche all-records complète incluant des réponses TXT utiles pour DKIM et DMARC, groupées par type avec actions de copie. Il sert à vérifier la configuration, documenter les migrations et répondre « que montre l'arbre DNS public pour ce nom aujourd'hui ? » Il ne trace pas une carte mondiale des différences entre resolvers et ne prétend pas tester cinquante emplacements globaux simultanément.

Les vérificateurs de propagation DNS dédiés interrogent de nombreux resolvers récursifs régionaux dans le temps et visualisent quelles régions cachent encore d'anciennes valeurs A, MX ou NS. Cette vision globale aide après de gros changements TTL ou swaps de nameserver quand le support demande « est-ce propagé ? » DN01 ne reproduit pas cette carte — nous visons un snapshot de qualité plus historique, accès API et outils compagnons (DIG, WHOIS, SSL) sur le même site.

La propagation n'est pas une téléportation instantanée. Ce sont d'anciens caches expirant selon TTL plus mises à jour glue registrar quand les nameservers changent. Un TTL bas dans la zone autoritative aide les futurs changements à converger plus vite mais ne peut pas vider rétroactivement des réponses déjà en cache à 86400 secondes. Utilisez le DNS Checker pour confirmer votre publication autoritative, puis des cartes de propagation si vous avez besoin de confiance géographique que des resolvers dans plusieurs régions ont expiré d'anciennes données.

Quand les réponses diffèrent entre le DNS Checker et une carte de propagation, les deux peuvent être « correctes » pour leur point de vue. Les resolvers récursifs cachent indépendamment ; DNS bureau, opérateur mobile et 8.8.8.8 peuvent diverger jusqu'à expiration TTL. Interrogez les NS autoritaires directement avec DIG quand vous devez contourner entièrement le cache — si les NS autoritaires montrent déjà le nouveau MX mais le checker l'ancien, vous observez un lag de cache, pas un publish raté.

Choisissez DN01 quand vous voulez chaque type majeur dans une vue, UI localisée en huit langues, historique récent local et API documentée pour l'automatisation. Choisissez les cartes de propagation quand votre question est spécifiquement « quelles régions voient encore l'ancienne IP ? » — pas « mes chaînes MX et SPF sont-elles correctes ? » Nous sommes honnêtes sur cette limite : pas de fausse barre de pourcentage de propagation, pas de grille globale simulée — seulement des données DNS précises et copiables pour les opérateurs qui doivent livrer des changements mail, web et certificats fiables.