Domain & DNS

Recherche d'enregistrements DNS

Interroge les enregistrements A, AAAA, MX, TXT, NS, CNAME et SOA.

Domain or IP Enter a domain. For PTR choose it as the only type and enter an IP.
Record types
PTR lives in the reverse (arpa) zone and cannot be combined with other record types.
Resolver

À propos de cet outil

Une recherche DNS demande à un résolveur faisant autorité ou récursif quels enregistrements un domaine publie. Notre outil exécute une requête en direct contre Google, Cloudflare ou Quad9 et vous montre chaque enregistrement avec son TTL — les mêmes données que dig imprime sur la ligne de commande, formatées pour un balayage rapide.

Vous pouvez extraire les types d'enregistrements courants sur une seule page : A et AAAA pour les hôtes, MX pour le routage du courrier, TXT pour les chaînes SPF/DKIM/vérification, NS pour la délégation, SOA pour les métadonnées de zone, plus CNAME, SRV, CAA et PTR inverse. Choisissez uniquement les types dont vous avez besoin pour garder la réponse compacte.

Quand utiliser cet outil

  • Après un changement DNS. Interrogez plusieurs résolveurs pour confirmer qu'un nouvel enregistrement est en direct avant d'y diriger le trafic.
  • Déboguer la délivrabilité des emails. Inspectez les enregistrements MX, SPF, DKIM et DMARC en une seule passe.
  • Vérification de propriété. Récupérez l'enregistrement TXT qu'un service tiers vous a demandé de publier.
  • DNS inverse. Exécutez une requête PTR sur une IP pour trouver le nom d'hôte qu'un serveur de messagerie ou un enregistreur lui attribuera.

Pourquoi vous pouvez voir des réponses différentes

Les résolveurs publics mettent en cache les enregistrements pendant le TTL que vous avez configuré sur votre serveur de noms faisant autorité. Google peut toujours servir l'ancienne valeur tandis que Cloudflare affiche déjà la nouvelle. Changez le résolveur pour comparer — la colonne TTL vous indique quand le cache expirera. Pour une vue globale sur 20+ points d'observation, voir la vérification de propagation liée ci-dessous.

Questions fréquentes

Quel résolveur DNS devrais-je utiliser ?

Les trois (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) sont publics, en anycast et renvoient des réponses provenant d'une source faisant autorité. Cloudflare a tendance à être le plus rapide ; Quad9 filtre les noms malveillants connus ; Google a le comportement le plus prévisible à travers les régions. Basculez entre eux pour voir si un problème est global ou spécifique au résolveur.

Qu'est-ce que la colonne TTL ?

Time-to-live en secondes — combien de temps un résolveur en aval est autorisé à mettre cet enregistrement en cache. Un TTL bas (60–300s) signifie que les changements se propagent rapidement ; un TTL élevé (3600–86400s) signifie que l'enregistrement est stable. Si vous êtes sur le point de changer un enregistrement, abaissez d'abord son TTL et attendez que l'ancien TTL s'écoule avant de basculer.

Interrogez-vous directement le serveur de noms faisant autorité ?

Non — nous interrogeons le résolveur public que vous sélectionnez, de la même manière qu'un navigateur ou un serveur de messagerie le ferait. C'est généralement ce que vous voulez : cela correspond à ce que le reste d'internet voit. Si vous avez besoin de vérifier ce que le serveur faisant autorité publie actuellement, utilisez un dig +norecurse ou un outil spécifique à l'hébergement.

Pourquoi les enregistrements PTR semblent-ils différents ?

Une recherche PTR résout une IP en un nom d'hôte et utilise la zone inverse .in-addr.arpa (IPv4) ou .ip6.arpa (IPv6). Pour éviter de mélanger les types d'enregistrements qui vivent dans différentes zones, choisissez PTR seul et saisissez une adresse IP au lieu d'un domaine.

Le résultat est-il mis en cache ?

Nous mettons en cache les réponses du résolveur pendant cinq minutes afin que les recherches répétées contre le même domaine et résolveur ne gaspillent pas le budget de requêtes en amont. Si vous avez besoin de forcer une nouvelle requête, changez le résolveur ou attendez la fenêtre de cinq minutes. Les TTL faisant autorité sont signalés sans changement — notre cache n'affecte que la fréquence à laquelle notre backend réinterroge.