Outil DNS Lookup

Vue d’ensemble

Le DNS est l’étape qui précède toutes les autres. Quand un site est inaccessible, quand du courrier rebondit, ou quand un déploiement est parti mais que personne ne le voit, la première question est presque toujours de savoir vers quoi le nom se résout actuellement — et la deuxième, qui vous le dit.

Cet outil interroge un résolveur DNS-over-HTTPS public pour les six types d’enregistrements dont vous avez le plus souvent besoin, et affiche les réponses avec leurs TTL. Comme un navigateur ne peut pas ouvrir de socket DNS, la requête passe par notre API au lieu de rester locale ; c’est la seule chose sur ce site qui doive quitter votre machine, et la politique de confidentialité décrit exactement ce qu’il en advient.

Utilisation

1. Saisissez un domaine — example.com, pas https://example.com/path.
2. Lisez les enregistrements. Chaque ligne affiche son type, son nom, sa valeur et son TTL.
3. Utilisez les boutons de type pour filtrer ce qui est déjà à l’écran. Ils n’envoient pas de nouvelle requête.

Ce que chaque type d’enregistrement vous apprend

La colonne MX affiche la priorité séparément de l’hôte, parce que ce nombre est une préférence et non un classement de qualité : le plus petit gagne, et des valeurs égales signifient que l’expéditeur peut choisir l’un ou l’autre. Un domaine sans aucun enregistrement MX peut tout de même recevoir du courrier sur son enregistrement A, en vertu d’une règle de MX implicite : c’est légal, et presque toujours accidentel.

Lire les TTL

Le TTL est la durée, en secondes, pendant laquelle le résolveur compte conserver cette réponse. Il décompte, donc le nombre que vous voyez est la durée de vie restante d’une entrée en cache, pas la valeur configurée dans la zone. Interrogez deux fois à une minute d’intervalle et vous le verrez généralement diminuer.

C’est le nombre le plus utile pendant une migration. Un enregistrement dont le TTL vaut 86400 sera encore servi depuis les caches jusqu’à un jour après votre modification, quelle que soit la rapidité avec laquelle votre fournisseur DNS applique l’édition. Le remède doit intervenir avant le changement : abaissez le TTL à 300, attendez l’expiration de l’ancien TTL, faites la modification, puis remontez le TTL.

Pourquoi les réponses diffèrent d’un outil à l’autre

Deux résolveurs peuvent légitimement se contredire, et savoir pourquoi épargne beaucoup de confusion :

• L’état du cache. Cet outil lit le résolveur de Cloudflare. Le résolveur de votre fournisseur d’accès a son propre cache, avec son propre décompte.
• Le routage géographique. Beaucoup de grands sites répondent avec l’adresse la plus proche du résolveur, si bien qu’une réponse obtenue depuis un centre de données Cloudflare n’est pas celle que votre ordinateur portable obtiendrait.
• Le DNS à horizon dédoublé. Un réseau d’entreprise peut servir des adresses internes pour un nom qui se résout publiquement vers autre chose. Un résolveur public ne voit jamais la vue interne.

Pour savoir « ce que dit le serveur autoritaire, à l’instant, sans aucun cache », il vous faut dig @<nameserver> <name> <type> visant l’un des hôtes NS que cet outil liste. C’est la vérité de terrain ; tout le reste est un cache.

Exemples

• Le courrier rebondit. Vérifiez d’abord MX, puis cherchez l’enregistrement SPF dans TXT. Deux enregistrements SPF sur un même domaine constituent un échec définitif au sens de la spécification, et c’est une conséquence fréquente de l’ajout d’un nouvel expéditeur sans suppression de l’ancienne ligne.
• Un sous-domaine renvoie 404 après un déploiement. Vérifiez s’il s’agit d’un CNAME pointant vers un nom d’hôte de plateforme qui a été renommé.
• Un domaine a été transféré et quelque chose est périmé. Comparez NS à ce que montre le registraire. Une divergence signifie que la zone que vous éditez n’est pas la zone qui est servie.
• Vérifier un service. Les jetons de vérification de domaine vivent dans TXT, et l’échec le plus fréquent consiste à ajouter l’enregistrement sur www plutôt qu’à l’apex.

Remarques

Le domaine est validé contre un motif de nom d’hôte avant l’émission de la requête, si bien que les URL, les adresses IP et les noms internationalisés sous forme Unicode sont rejetés plutôt que transmis tels quels. Pour un domaine internationalisé, convertissez-le d’abord en Punycode avec le convertisseur IDN.

Les enregistrements sont étiquetés avec le type renvoyé par le résolveur plutôt qu’avec celui demandé. Cela compte pour les hôtes en alias : demander A sur un nom qui est un CNAME renvoie l’alias plus les adresses résolues, et étiqueter à tort l’alias comme un enregistrement d’adresse serait activement trompeur.

Un résultat vide est une réponse valide, pas un échec. Un domaine sans enregistrement AAAA n’a simplement pas d’adresse IPv6, et un domaine sans enregistrement TXT n’a rien de configuré — ni l’un ni l’autre n’est une erreur qu’il faudrait signaler comme telle.

Pour voir ce que le serveur résolu renvoie effectivement en HTTP, enchaînez avec le vérificateur d’en-têtes HTTP.