Outils populaires

Thème

Recherche DNS

Outil de recherche DNS (DNS lookup) gratuit pour tout domaine, hôte ou adresse IP : tous les enregistrements DNS depuis les serveurs de noms du domaine, à côté de ce que Google et Cloudflare ont en cache, pour voir quand une modification atteint tout le monde.

Sources : les serveurs de noms faisant autorité du domaine, atteints depuis un serveur racine · Google Public DNS · Cloudflare 1.1.1.1

3 sources, interrogées à neuf

Un domaine, un hôte, une URL, une adresse e-mail ou une IP. Chaque recherche réinterroge les serveurs : rien ne vient de notre cache.

Type d'enregistrement
Essayez

Comment nous cherchons 4 étapes · environ 1 s

  1. Racine13 serveurs racine
  2. TLDles serveurs du registre
  3. Serveur de nomsles serveurs du domaine
  4. Réponsetous les types
  5. Google8.8.8.8
  6. Cloudflare1.1.1.1

Chaque recherche parcourt elle-même le chemin : d'un serveur racine au registre du TLD, puis aux serveurs de noms du domaine pour les enregistrements tels qu'ils sont maintenant, et demande à Google et à Cloudflare ce qu'ils gardent encore en cache.

Ce que montre une recherche DNS

Une recherche DNS (DNS lookup) interroge le système de noms de domaine sur ce qu'il contient pour un nom : les adresses IP d'un site web (A et AAAA), ses serveurs de messagerie (MX), ses serveurs de noms (NS), ses enregistrements texte (TXT) et plus encore. Pour vérifier un DNS, cet outil interroge trois sources à la fois : les serveurs de noms faisant autorité du domaine, qui détiennent la version actuelle, et deux des résolveurs publics les plus sollicités au monde, Google Public DNS et Cloudflare 1.1.1.1, qui servent des copies en cache à des millions de personnes.

Quand ils ne concordent pas, vous tenez la raison habituelle pour laquelle une modification DNS « ne fonctionne pas » : un résolveur a encore l'ancienne réponse et la garde jusqu'à l'expiration du TTL de l'enregistrement. Le résultat indique lequel, ce qu'il sert encore et dans combien de temps il se mettra à jour.

Recherche DNS : enregistrements des serveurs de noms du domaine face au cache de Google et Cloudflare, chemin et DNSSECRecherche DNS : enregistrements des serveurs de noms du domaine face au cache de Google et Cloudflare, chemin et DNSSECLe cheminD'un serveur racine au TLD du domaine puis à ses propres serveurs de noms, avec la réponse de chacun et sa rapidité.Frais ou en cacheChaque type d'enregistrement des serveurs de noms du domaine à côté de la copie de Google et de Cloudflare, avec le temps qu'il lui reste.Chaque enregistrement expliquéCe que signifie une valeur, en mots : priorité de messagerie, minuteurs SOA, règles CAA, le service derrière un jeton TXT.DNSSEC et e-mailSi les réponses sont signées et validées, et la configuration MX, SPF et DMARC du domaine.
Une recherche DNS sur github.com : le chemin depuis la racine, chaque type d'enregistrement et ce que servent Google et Cloudflare. Sélectionnez un numéro pour voir ce que montre chaque partie.

Les types d'enregistrements DNS expliqués

La zone d'un domaine contient des enregistrements de différents types, chacun avec un nom, un TTL et une valeur. Voici ceux qu'affiche une recherche d'enregistrements DNS :

TypeCe qu'il contientExemple de valeur
AUne adresse IPv4 pour le nom : celle à laquelle les navigateurs se connectent.203.0.113.20
AAAAUne adresse IPv6 pour le nom.2001:db8::20
CNAMEUn alias : ce nom en désigne un autre, qu'il faut rechercher à la place. Il ne peut pas coexister avec d'autres enregistrements, donc pas à l'apex du domaine.www.example.com → example.com
MXUn serveur de messagerie du domaine, avec une préférence : le plus petit nombre est essayé en premier. Un MX unique de 0 pointant vers « . » signifie que le domaine ne reçoit aucun e-mail.10 mail.example.com
NSLes serveurs de noms qui détiennent les enregistrements du domaine.ns1.example.net
TXTDu texte libre : SPF, DMARC et DKIM pour l'e-mail, et des jetons qui prouvent la propriété du domaine à Google, Microsoft et d'autres.v=spf1 include:_spf.example.net -all
SOALe début d'autorité de la zone : son serveur principal, son contact, son numéro de série et ses minuteurs d'actualisation, de nouvelle tentative, d'expiration et de cache négatif.ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300
CAALes autorités de certification autorisées à émettre des certificats pour le domaine.0 issue "letsencrypt.org"
HTTPSComment se connecter avant la première requête : prise en charge de HTTP/3, ports et indices d'adresse. Chrome, Firefox et les systèmes d'Apple le demandent.1 . alpn=h3,h2
SRVOù tourne un service (priorité, poids, port, hôte), sous des noms comme _sip._tcp.10 5 5060 sip.example.com
PTRLe nom derrière une adresse IP : le DNS inverse.20.113.0.203.in-addr.arpa → host.example.com
DSDNSKEYDNSSEC : les clés publiques de la zone (DNSKEY) et leur empreinte dans la zone parente (DS), qui relient les signatures jusqu'à la racine.2371 13 2 3299…

Comment fonctionne une recherche DNS ?

Votre appareil ne fouille pas tout internet. Il interroge un seul résolveur, généralement celui de votre FAI ou un résolveur public comme Google ou Cloudflare, et ce résolveur suit les renvois le long du nom jusqu'à ce qu'un serveur qui détient la réponse réponde :

  1. 1

    Interroger un serveur racine

    Sans rien en cache, le résolveur commence par l'un des 13 serveurs racines, de a à m, exploités par 12 organisations. La racine ne connaît pas example.com, mais elle sait qui gère le .com. Un résolveur très sollicité le sait déjà et saute cette étape.

  2. 2

    Suivre le renvoi vers le TLD

    Les serveurs du .com ne détiennent pas non plus les enregistrements d'example.com. Ils renvoient le résolveur vers les serveurs de noms du domaine, ceux de ses enregistrements NS.

  3. 3

    Obtenir la réponse faisant autorité

    Les serveurs de noms du domaine répondent avec le flag AA (authoritative answer) positionné : c'est l'enregistrement tel que son propriétaire l'a publié.

  4. 4

    La mettre en cache pendant le TTL

    Le résolveur garde la réponse aussi longtemps que son TTL l'indique et remet la même copie, avec son TTL qui décompte, à tous ceux qui la demandent jusqu'à son expiration.

Cet outil parcourt lui-même ce chemin depuis le réseau de Cloudflare : vous voyez donc chaque étape. Il demande ensuite à Google et à Cloudflare de montrer ce que contiennent leurs caches.

Chemin depuis la racine

  1. Racinea.root-servers.net16 ms · renvoi : les 13 serveurs du .com
  2. .COMa.gtld-servers.netVerisign · 150 ms · renvoi : ns1–ns2.example.com
  3. Serveur de nomsns1.example.comexample.com · 203.0.113.53 · 20 msréponse faisant autorité (AA) · 11 types sur une seule connexion TCP
  4. Réponse8 enregistrements de 7 typesNOERROR en 31 ms · 4 sans enregistrement (CNAME, HTTPS, DNSKEY, DS)
  1. Google Public DNS8.8.8.8mêmes enregistrements · la plus ancienne copie se renouvelle dans 2:58
  2. Cloudflare DNS1.1.1.1mêmes enregistrements · la plus ancienne copie se renouvelle dans 4:04
Le même chemin, tel que le résultat le dessine : une recherche sur example.com

Pourquoi vois-je encore l'ancien enregistrement DNS ?

Parce qu'un résolveur l'a mis en cache. Chaque enregistrement porte un TTL (time to live, ou durée de vie) en secondes, et un résolveur qui a récupéré l'enregistrement continue de servir sa copie jusqu'à l'expiration de ce délai, puis le redemande. Modifier l'enregistrement chez votre hébergeur DNS change immédiatement la réponse faisant autorité ; les résolveurs qui ont déjà l'ancienne la gardent jusqu'à son expiration.

Une modification prend donc le temps du TTL de l'ancien enregistrement, et non un délai fixe de 24 à 48 heures, et souvent moins : un TTL est un maximum, et Google Public DNS garde les enregistrements environ six heures au plus. Un enregistrement absent est mis en cache lui aussi : « ce nom n'existe pas » ou « aucun enregistrement de ce type » est conservé pendant la plus petite de deux valeurs, le TTL de l'enregistrement SOA et son dernier champ, MINIMUM. Même un échec est mis en cache, jusqu'à 5 minutes.

Ce que vous pouvez faire

  • Vérifiez ici la réponse faisant autorité. Si les serveurs de noms du domaine affichent la nouvelle valeur, la modification est faite ; seuls les caches sont en retard.
  • Abaissez le TTL avant une modification planifiée, au moins un ancien TTL à l'avance, pour que les caches abandonnent vite l'ancienne valeur. Remontez-le ensuite.
  • Demandez à Google et à Cloudflare d'abandonner leur copie : tous deux ont une page publique qui actualise un nom dans leur cache (Google, Cloudflare).
  • Videz le cache de votre ordinateur : sous Windows, lancez ipconfig /flushdns.
  • Faisant autoriténs1.example.com · flag AA

    Le serveur de noms du domaine lui-même. Ce qu'il répond est l'enregistrement actuel : modifiez-le ici et le reste suit.

  • En cache8.8.8.8 · TTL en décompte

    La copie d'un résolveur, servie jusqu'à l'expiration de son TTL. C'est ce que voit la plus grande partie du monde, et la raison pour laquelle une modification semble « ne pas fonctionner ».

  • Votre propre cachevotre ordinateur · votre routeur

    Votre ordinateur et votre routeur gardent aussi des copies. Vider le cache efface la première ; celle du routeur expire d'elle-même.

nslookup et dig : les commandes de recherche DNS

Les mêmes recherches depuis un terminal : nslookup est fourni avec Windows, macOS et Linux, dig avec macOS et la plupart des systèmes Linux, et Resolve-DnsName avec PowerShell sous Windows. Le résultat ci-dessus donne les commandes de la recherche exacte que vous avez lancée.

Pour recherchernslookupdig
Les enregistrements Anslookup example.comdig example.com
Les serveurs de messagerienslookup -type=MX example.comdig example.com MX
Les enregistrements textenslookup -type=TXT example.comdig example.com TXT
Interroger un seul résolveurnslookup example.com 8.8.8.8dig @8.8.8.8 example.com
Le DNS inversenslookup 8.8.8.8dig -x 8.8.8.8
Uniquement les valeurs—dig +short example.com
Le chemin depuis la racine—dig +trace example.com

« Non-authoritative answer » dans la sortie de nslookup signifie que la réponse vient d'un résolveur, et non des serveurs de noms du domaine. Pour obtenir la réponse faisant autorité, indiquez l'un des serveurs de noms du domaine comme serveur : nslookup example.com ns1.example.net.

ANY ne signifie pas tous les enregistrements : un serveur peut répondre avec un seul type, ou avec un enregistrement de substitution qui indique seulement « RFC8482 », et le 1.1.1.1 le refuse. Cet outil demande chaque type séparément. Le dig fourni avec macOS ne connaît pas les enregistrements HTTPS : demandez plutôt TYPE65.

Erreurs DNS : NXDOMAIN, SERVFAIL et REFUSED

Chaque réponse DNS porte un code de réponse. Un résultat vide n'est pas toujours une erreur, et le code indique où chercher :

RéponseCe que cela signifieCe qu'il faut vérifier
NOERRORLe nom existe et des enregistrements du type demandé sont revenus.Rien ; comparez les valeurs.
NODATALe nom existe, mais n'a aucun enregistrement de ce type : NOERROR avec une réponse vide, pas un code à part entière.Ajoutez l'enregistrement chez votre hébergeur DNS s'il doit exister.
NXDOMAINLe nom n'existe pas du tout, et aucun nom en dessous de lui non plus.L'orthographe, que le domaine est enregistré et n'a pas expiré, et pour un sous-domaine, qu'il a bien été créé.
SERVFAILLe résolveur n'a pas pu obtenir de réponse valide : les serveurs de noms ont échoué, ou la validation DNSSEC a échoué.Le verdict DNSSEC, et que les serveurs de noms du domaine répondent.
REFUSEDLe serveur refuse de répondre à cette question : il ne fait pas autorité pour le domaine et n'effectue pas de résolution récursive pour vous.Que les enregistrements NS pointent vers des serveurs qui hébergent la zone.
TimeoutAucune réponse.Les serveurs de noms sont hors service, bloqués ou ont une mauvaise adresse.

DNSSEC : sécurisé, non signé ou défaillant ?

DNSSEC signe les enregistrements d'une zone pour qu'un résolveur puisse prouver qu'ils n'ont pas été falsifiés. La zone parente publie un enregistrement DS, une empreinte de la clé du domaine, et le domaine publie ses clés dans des enregistrements DNSKEY : les signatures remontent ainsi jusqu'à la racine. Google Public DNS et Cloudflare 1.1.1.1 le valident tous les deux.

  • DNSSEC sécurisé

    Sécurisé

    Signé, et le résolveur validant de Google a vérifié les signatures : sa réponse portait le bit AD (authenticated data), sa façon d'affirmer que la réponse a été validée.

  • DNSSEC non signé

    Non signé

    Aucun enregistrement DS chez le parent : la zone n'est pas signée. Elle se résout normalement ; ses réponses ne peuvent simplement pas être prouvées authentiques.

  • DNSSEC défaillant

    Défaillant

    La validation échoue : les résolveurs qui valident répondent SERVFAIL et le domaine est injoignable pour leurs utilisateurs, alors que les données sont bien là quand la vérification est désactivée. Cause typique : un DS chez le parent qui ne correspond à aucune des clés de la zone, après un passage chez un nouvel hébergeur DNS.

Les enregistrements e-mail dans une recherche DNS

Les e-mails d'un domaine vont à ses serveurs MX, et les destinataires vérifient des enregistrements TXT avant de leur faire confiance : SPF liste les serveurs autorisés à envoyer pour le domaine, dans un seul enregistrement qui peut entraîner au plus 10 requêtes DNS ; DMARC, sous _dmarc, indique quoi faire des e-mails qui échouent, et se trouve en remontant le nom quand un sous-domaine n'en a pas (RFC 9989, depuis mai 2026) ; MTA-STS, sous _mta-sts, demande aux expéditeurs de livrer via TLS. Le résultat les lit tous et nomme le fournisseur de messagerie derrière les hôtes MX.

Pour vérifier un enregistrement plus en profondeur, utilisez la Recherche MX, le Vérificateur SPF et le Vérificateur DMARC.

API de recherche DNS

Deux points de terminaison gratuits, avec CORS pour les navigateurs. /api/dns-query interroge un résolveur pour un type et conserve les champs de notre ancienne API ; /api/dns-lookup diffuse la recherche complète de cette page en lignes JSON.

Un type depuis un résolveur
$ curl -X POST https://dnsrobot.net/api/dns-query \
    -H "Content-Type: application/json" \
    -d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
  "status": "success", "responseTime": 4,
  "resolvedIPs": ["10 smtp.google.com"],
  "dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}
La recherche complète, en flux
$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}

FAQ sur la recherche DNS

Qu'est-ce qu'une recherche DNS (DNS lookup) ?

Une recherche DNS interroge le système de noms de domaine sur les enregistrements d'un nom : les adresses IP d'un site web, ses serveurs de messagerie, ses serveurs de noms, ses enregistrements texte et plus encore. Votre appareil en fait une chaque fois que vous ouvrez un site. Cet outil affiche tous les types d'enregistrement à la fois, depuis les serveurs de noms du domaine et depuis les résolveurs publics de Google et de Cloudflare.

Comment vérifier les enregistrements DNS d'un domaine ?

Saisissez le domaine ci-dessus et choisissez Tous : l'outil demande chaque type d'enregistrement (A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, HTTPS, DNSKEY et DS) aux serveurs de noms faisant autorité du domaine et affiche à côté la copie en cache de Google et de Cloudflare. Choisissez un seul type, par exemple A pour vérifier l'enregistrement A d'un domaine, ou copiez les commandes dig et nslookup pour lancer la même recherche vous-même.

Peut-on faire un nslookup en ligne ?

Oui : cette page est un nslookup en ligne, en plus détaillé. nslookup interroge un serveur pour un type d'enregistrement ; ici, vous obtenez tous les types à la fois, la réponse faisant autorité et le cache de deux résolveurs, les TTL et le chemin depuis la racine. Le résultat affiche aussi les commandes nslookup, dig et Resolve-DnsName exactes de votre recherche, à lancer dans un terminal.

Combien de temps faut-il pour qu'une modification DNS soit visible ?

Le temps du TTL de l'ancien enregistrement. Les serveurs de noms du domaine servent la nouvelle valeur immédiatement, mais les résolveurs qui ont mis l'ancienne en cache la gardent jusqu'à l'expiration de son TTL : 300 secondes font cinq minutes, 86400 une journée. Le résultat affiche le temps restant sur les copies de Google et de Cloudflare. Abaissez le TTL la veille d'une modification planifiée.

Qu'est-ce qu'une réponse ne faisant pas autorité ?

Une réponse issue du cache d'un résolveur plutôt que des serveurs de noms du domaine. nslookup affiche « Non-authoritative answer » chaque fois que vous interrogez un résolveur, c'est-à-dire presque toujours. Elle est généralement juste, mais peut être dépassée jusqu'à l'expiration de son TTL. Une réponse faisant autorité vient des serveurs de noms de la zone, avec le flag AA positionné ; cet outil en obtient une en descendant depuis la racine.

Que signifie NXDOMAIN ?

NXDOMAIN signifie que le nom n'existe pas dans le DNS. Pour un domaine, vérifiez l'orthographe et qu'il est enregistré et n'a pas expiré ; la Recherche WHOIS affiche son statut. Pour un sous-domaine, l'enregistrement n'a jamais été créé ou a été supprimé. Un nom qui existe mais n'a aucun enregistrement du type demandé reçoit à la place NOERROR avec une réponse vide, souvent appelée NODATA.

Que signifie SERVFAIL ?

SERVFAIL signifie que le résolveur n'a pas pu obtenir de réponse valide. Soit les serveurs de noms du domaine sont hors service ou mal configurés, soit la validation DNSSEC a échoué, ce qui pousse les résolveurs qui valident, comme Google et Cloudflare, à refuser la réponse. Cet outil distingue les deux cas : quand les données reviennent avec la vérification désactivée, le verdict DNSSEC indique Défaillant.

Qu'est-ce que le TTL dans le DNS ?

Le TTL (time to live, ou durée de vie) est le nombre de secondes pendant lesquelles un résolveur peut garder un enregistrement en cache avant de le redemander. Chaque enregistrement a le sien. Un TTL court comme 300 secondes propage vite les modifications mais coûte plus de requêtes ; un TTL long comme 86400 secondes (une journée) est plus économique mais lent à changer. Les copies en cache décomptent, d'où les TTL plus bas de Google et de Cloudflare ici.

Comment faire une recherche DNS inverse ?

Saisissez l'adresse IP ci-dessus. L'outil la convertit en nom inverse (8.8.8.8 devient 8.8.8.8.in-addr.arpa), demande l'enregistrement PTR, puis vérifie ce nom par résolution directe : quand il se résout bien en la même IP, le DNS inverse est confirmé, ce que vérifient les serveurs de messagerie. Depuis un terminal : nslookup 8.8.8.8 ou dig -x 8.8.8.8.

Comment vérifier les serveurs de noms d'un domaine ?

Recherchez le domaine et lisez les enregistrements NS, ou le chemin à droite : il montre les serveurs de noms vers lesquels renvoie le TLD du domaine, et les signale si les propres enregistrements NS du domaine en listent d'autres. Le résultat nomme aussi l'entreprise qui les gère, comme Cloudflare, AWS Route 53 ou le registrar du domaine.

Quelle différence entre une recherche DNS et une vérification de propagation DNS ?

Une recherche DNS affiche tous les enregistrements d'un domaine avec leurs détails, depuis ses propres serveurs de noms et deux grands résolveurs. Une vérification de propagation demande un type d'enregistrement à des dizaines de résolveurs dans le monde pour voir où une modification est arrivée. Commencez ici pour voir la réponse qui fait foi et le cache, puis utilisez le vérificateur de propagation DNS de notre page d'accueil pour la vue mondiale.

Cette recherche DNS est-elle gratuite, et gardez-vous ce que je recherche ?

Elle est gratuite, sans compte et sans CAPTCHA ; pour protéger les serveurs que nous interrogeons, un même réseau peut lancer 20 recherches par minute. La recherche s'exécute sur notre serveur, sur le réseau de Cloudflare : les serveurs de noms du domaine voient donc notre adresse, pas la vôtre. Rien n'est mis en cache : chaque recherche interroge de nouveau. Nous n'enregistrons pas qui a recherché quoi.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Autres outils DNS