DNS Lookup — ce qu'il répond et comment lire sa sortie

Presque chaque incident qui commence par « le site est en panne » ou « le courriel ne nous parvient plus » finit par une requête DNS. Avant de sortir dig sur un bastion, une requête côté navigateur contre un résolveur public connu est plus rapide, partageable, et permet à une personne non technique de vous coller la même URL quand la réponse change. C’est précisément à ça que sert le DNS Lookup de PortJar.

Ce que l’outil fait

DNS Lookup interroge un résolveur récursif public et retourne tous les types d’enregistrements courants — A, AAAA, MX, TXT, NS, SOA, CAA, SRV, CNAME — pour un domaine que vous spécifiez. La réponse reflète ce que le résolveur a actuellement en cache, ce qui correspond généralement à ce que le reste de l’internet voit, à quelques secondes près d’un changement. La sortie est structurée : chaque type d’enregistrement est dans son propre bloc, donc on peut copier une seule entrée TXT sans grepper dans un mur de texte.

Parce qu’il passe par un résolveur récursif plutôt que par les serveurs autoritaires, il donne la même réponse que celle que le résolveur d’un usager type retournerait. C’est cette réponse qui compte quand quelqu’un dit que le site ne charge pas — pas ce que le panneau de contrôle du registraire prétend être configuré.

Comment l’utiliser

Ouvrez portjar.com/tools/dns-lookup, tapez le domaine (sans schéma, sans chemin), et choisissez le type d’enregistrement. Laissez le type à ALL quand vous diagnostiquez un problème inconnu et voulez une vue d’ensemble d’un coup. Choisissez un type précis — MX, TXT, CAA — quand vous savez déjà ce que vous cherchez et voulez la réponse plus vite.

Si le résultat vous surprend, copiez l’URL et envoyez-la au client ou au registraire. La page est sans état, donc le destinataire voit la même requête et une réponse fraîche.

Quand vous y recourriez

• Un nouveau domaine vient d’être délégué à vos serveurs de noms et vous voulez confirmer que NS et SOA correspondent à ce que vous avez provisionné, avant d’annoncer la bascule.
• Un renouvellement Let’s Encrypt a échoué avec CAA record forbids issuance et vous devez voir ce qui est réellement publié comme CAA, y compris les enregistrements hérités de l’apex. PortJar pointe vers le contexte de dépannage plus large pour ce scénario.
• Un client signale que le courriel rebondit — sortez les MX pour confirmer que les priorités et les hôtes pointent toujours là où prévu, puis enchaînez vers MX Diagnostics de PortJar pour la sonde plus poussée.
• Un fournisseur vous demande d’ajouter un jeton de vérification TXT et vous voulez confirmer qu’il s’est propagé avant de fermer le billet.
• Vous soupçonnez qu’une chaîne CNAME est devenue obsolète (par exemple, un point de terminaison SaaS qui a changé de cible) et vous voulez voir le chemin de résolution complet sans ouvrir un shell.

Quoi faire de la sortie

Un résultat vide pour un type d’enregistrement qui devrait exister est la forme la plus courante — et ça veut presque toujours dire que l’enregistrement n’a jamais été publié, ou qu’il a été publié avec le mauvais nom (apex vs sous-domaine) chez le registraire. Traitez un MX vide sur un domaine qui envoie du courriel comme un manque de configuration, pas comme un échec de l’outil.

Plusieurs enregistrements A retournés dans des ordres différents sur des requêtes répétées, c’est normal — c’est de l’équilibrage en round-robin, pas un bogue. Plusieurs enregistrements TXT sur l’apex aussi, c’est normal ; on voit couramment SPF, une vérification de site Google, une vérification Microsoft 365 et un jeton de propriété de domaine d’un fournisseur cohabiter. Lisez chacun indépendamment avant de signaler « il y en a trop ».

Si la même requête retourne des réponses différentes selon que vous comparez PortJar à votre dig local, c’est une question de propagation, pas une question de DNS Lookup. Basculez vers le DNS Propagation Checker de PortJar et regardez la réponse de cinq résolveurs en parallèle. Un désaccord là veut dire qu’un changement est encore en cours de diffusion ; un accord veut dire que votre résolveur local a un cache périmé.

Stack Harbor utilise DNS Lookup comme première étape dans presque chaque bascule, prise en charge et vérification post-incident menée dans le cadre de la gestion de déploiement.