What is a DNS A record?

An A record (Address record) maps a domain name to an IPv4 address. When you type a URL, your browser performs a DNS lookup to find the A record and connect to that IP address.

What is the difference between A and AAAA records?

A records map to IPv4 addresses (e.g., 93.184.216.34). AAAA records map to IPv6 addresses (e.g., 2606:2800:220:1:248:1893:25c8:1946). Most modern websites have both.

What is a CNAME record used for?

A CNAME (Canonical Name) record aliases one domain name to another. For example, www.example.com might CNAME to example.com. The browser then looks up the target domain's A record to find the IP address.

Is this tool free to use?

Yes, this tool is completely free with no hidden charges, sign-up requirements, or usage limits. Use it as often as you need.

Cet outil fonctionne-t-il hors ligne ?

No. DNS lookups require a live network connection to the Cloudflare DNS-over-HTTPS endpoint. The UI itself runs in your browser, but the actual DNS query needs internet access.

Recherche DNS, gratuite

Interrogez les enregistrements DNS de n'importe quel domaine via DNS-over-HTTPS de Cloudflare.

Nom de domaine

Types d'enregistrements DNS expliqués

A · associe un domaine à une adresse IPv4

AAAA · associe un domaine à une adresse IPv6

CNAME · alias pointant vers un autre domaine

MX · serveurs de messagerie (avec priorité)

TXT · texte arbitraire (SPF, DKIM, vérification de domaine)

NS · serveurs de noms autoritaires pour le domaine

SOA · Start of Authority, infos du serveur de noms principal

PTR · DNS inverse, associe une IP à un domaine

Comment ça marche

Entrez un domaine : saisissez un nom de domaine (y compris les sous-domaines) dans le champ.
Sélectionnez les types d'enregistrements : choisissez quels types d'enregistrements DNS interroger : A, AAAA, MX, CNAME, TXT, NS, SOA ou tous.
Consultez les résultats : les résultats sont obtenus depuis un fournisseur DNS-over-HTTPS public et affichés avec les valeurs TTL et les données.
Diagnostiquez : comparez les résultats entre types d'enregistrements pour identifier une mauvaise configuration, des délais de propagation ou des enregistrements manquants.

Pourquoi utiliser la recherche DNS ?

Les problèmes DNS sont parmi les causes les plus fréquentes d'indisponibilité de sites web, d'échecs de livraison d'e-mails et de problèmes de migration de domaine. Pouvoir interroger les enregistrements DNS directement depuis le navigateur, sans recourir à des outils en ligne de commande comme dig ou nslookup: est précieux pour les développeurs, les DevOps et les administrateurs système. Cet outil interroge les enregistrements via DNS-over-HTTPS pour la confidentialité et le contournement des pare-feux. Utilisez-le pour vérifier les enregistrements MX après un changement de fournisseur d'e-mail, confirmer les enregistrements A/CNAME après une migration DNS, vérifier les enregistrements TXT pour l'authentification SPF/DKIM et diagnostiquer les délais de propagation.

Types d'enregistrements DNS

A: adresse IPv4 d'un domaine
AAAA: adresse IPv6 d'un domaine
MX: enregistrements de serveurs de messagerie pour le routage des e-mails
CNAME: alias de nom canonique pointant vers un autre domaine
TXT: enregistrements texte pour SPF, DKIM, vérification de domaine
NS: serveurs de noms autoritaires pour le domaine

40 ans de DNS : de RFC 882 à DNS sur QUIC

Le Domain Name System a été conçu par Paul Mockapetris à l'USC/ISI et spécifié dans les RFC 882 et RFC 883 (novembre 1983), remplaçant le fichier plat HOSTS.TXT que l'ARPANET avait dépassé. Le système a été remanié et formalisé dans les RFC 1034 et RFC 1035 (novembre 1987), les documents encore cités aujourd'hui. Jon Postel a coordonné l'attribution des 13 serveurs racines d'origine, étiquetés a.root-servers.net à m.root-servers.net, un nombre fixé non pas par la capacité mais par la limite de taille de paquet UDP de 512 octets de l'époque. Deux chocs majeurs ont remodelé le DNS au cours de ce siècle. En juillet 2008, Dan Kaminsky a divulgué une attaque de cache-poisoning qui permettait aux attaquants d'injecter des enregistrements forgés dans les résolveurs en quelques secondes. L'industrie a répondu avec un patch coordonné (randomisation du port source) et un regain d'intérêt pour DNSSEC (RFC 4033-4035, mars 2005), qui signe les enregistrements cryptographiquement. Le second choc fut la confidentialité : les requêtes voyageaient en texte clair sur le port UDP 53 pendant 35 ans. DNS sur TLS (DoT, RFC 7858, mai 2016) enveloppe les requêtes en TLS sur le port 853. DNS sur HTTPS (DoH, RFC 8484, octobre 2018) tunnelise les requêtes via HTTPS sur le port 443, cachant même le fait que du DNS a lieu. DNS sur QUIC (RFC 9250, mai 2022) est le plus récent, utilisant le même transport qui propulse HTTP/3. Les résolveurs publics 1.1.1.1 (Cloudflare, lancé le 1er avril 2018), 8.8.8.8 (Google Public DNS, décembre 2009) et 9.9.9.9 (Quad9, novembre 2017) supportent tous DoH et DoT aujourd'hui.

Types d'enregistrements en profondeur

A (RFC 1035). Adresse IPv4 32 bits. Un domaine peut avoir plusieurs enregistrements A pour l'équilibrage de charge ; les résolveurs y tournent (DNS round-robin).
AAAA (RFC 3596, 2003). Adresse IPv6 128 bits. Prononcé «quad-A». En 2024, environ 45 % du trafic de Google est en IPv6.
CNAME (RFC 1035). Alias : «suis ce nom et recherche ses enregistrements à la place». Ne peut coexister avec aucun autre enregistrement au même nom. C'est pourquoi example.com ne peut avoir à la fois un CNAME et un MX ou A à l'apex ; les alternatives modernes utilisent ALIAS ou ANAME (spécifiques au fournisseur) ou les enregistrements HTTPS (RFC 9460, 2023).
MX (RFC 1035, mis à jour par RFC 7505 «null MX»). Serveur de messagerie avec une valeur de priorité. Une priorité plus basse est préférée ; les égalités sont randomisées. 0 . (RFC 7505, juin 2015) dit explicitement «ce domaine ne reçoit pas de mail», bloquant le spam vers les domaines sans boîte aux lettres.
TXT (RFC 1035). Chaînes de texte libre. Porte maintenant une authentification critique : SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), et la vérification de propriété pour Google Search Console, Microsoft 365, ACME (Let's Encrypt) défis DNS-01.
NS (RFC 1035). Noms des serveurs de noms autoritatifs. Toujours au moins deux pour la redondance. Les «glue records» dans la zone parent fournissent des IP pour qu'un résolveur récursif puisse atteindre le serveur de noms sans recherches circulaires.
SOA (RFC 1035). Start of Authority. Enregistrement unique par zone listant le serveur de noms primaire, l'email admin (avec le premier . remplacé par @), le numéro de série (incrémenté sur les changements), refresh, retry, expire et TTL minimum.
CAA (RFC 8659, 2019 ; à l'origine RFC 6844, 2013). Certificate Authority Authorisation. Liste quelles CA sont autorisées à émettre des certificats pour le domaine. Vérification obligatoire par les exigences de base du CA/Browser Forum depuis septembre 2017.
SRV (RFC 2782, 2000). Localisation de service : protocole, priorité, poids, port, hôte cible. Microsoft Active Directory, XMPP, SIP, fédération Matrix utilisent tous les enregistrements SRV pour la découverte de service.
PTR (RFC 1035). DNS inverse. Mappe une IP de retour à un domaine. Vit dans les zones in-addr.arpa (IPv4) ou ip6.arpa (IPv6). Requis par de nombreux serveurs de mail pour accepter l'email ; un PTR manquant est un signal de spam courant.
DNSKEY / DS / RRSIG (RFC 4034-4035). Plomberie DNSSEC. Le DNSKEY publie les clés de signature de la zone ; DS dans la zone parent est le pointeur cryptographique «voici le lien suivant dans la chaîne» ; RRSIG porte la signature réelle pour chaque ensemble d'enregistrements.

Où la recherche DNS aide vraiment

Configurer l'email sur un nouveau domaine. Vérifiez que les enregistrements MX pointent vers le bon fournisseur (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Vérifiez SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
Migration de domaine et propagation. Après la mise à jour des serveurs de noms chez le registrar, interrogez à la fois les anciens et nouveaux serveurs autoritatifs pour confirmer que le changement s'est propagé mondialement. Différents résolveurs mettent en cache pour différentes durées (le TTL est un indice, pas un contrat).
Dépannage de certificat TLS / SSL. Le défi ACME DNS-01 utilisé par Let's Encrypt et similaires nécessite de placer un enregistrement TXT à _acme-challenge.example.com. Vérifiez la valeur avant de déclencher l'émission de certificat pour éviter les tentatives gaspillées de rate-limit.
Détection du risque de prise de contrôle de sous-domaine. Un CNAME pointant vers un service non enregistré (app Heroku supprimée, bucket S3 libéré) permet aux attaquants de l'enregistrer et de servir du contenu sur votre sous-domaine. Un audit CNAME rapide attrape les pointeurs orphelins.
Vérification CDN et équilibreur de charge. Confirmez qu'un domaine CNAME vers le bon point de terminaison Cloudflare, Fastly, Akamai, CloudFront ou Vercel après le déploiement. Détectez quand le staging pointe accidentellement vers la production.
Comparaison DNS géographique. Certains sites servent différents enregistrements A par région (GeoDNS). Interroger depuis différents points de terminaison DoH (Cloudflare 1.1.1.1 vs Google 8.8.8.8) suggère comment un utilisateur à Francfort vs Mumbai voit le site.
Sécurité et réponse aux incidents. Cherchez des enregistrements NS inattendus (détournement de registrar), des enregistrements TXT suspects ou des enregistrements MX récemment ajoutés. Utilisez le numéro de série SOA pour suivre quand une zone a changé pour la dernière fois.

Erreurs DNS qui cassent sites et email

CNAME à l'apex. RFC 1034 interdit de mettre un CNAME sur example.com lui-même (seulement sur les sous-domaines comme www.example.com). Cloudflare, Route 53, DNSimple contournent cela avec le CNAME flattening ou les enregistrements ALIAS ; Vercel, Netlify utilisent les enregistrements de liaison de service HTTPS (RFC 9460). L'essayer sur le panneau DNS d'un registrar basique casse silencieusement l'email.
Oublier de baisser le TTL avant une migration. Si votre enregistrement A a un TTL 86400 (24 heures) et que vous le changez le matin du basculement, les résolveurs du monde entier continueront de distribuer l'ancienne IP jusqu'à un jour. Baissez les TTL à 300 secondes quelques jours avant le changement.
Enregistrement SPF avec trop de recherches DNS. RFC 7208 plafonne SPF à 10 recherches DNS par évaluation. Enchaîner trop de directives include: et votre enregistrement SPF échoue avec permerror, que DMARC traite comme un échec. Aplatissez ou consolidez avec des outils comme SPF Surveyor.
CNAME pendant après démontage de service. Supprimé l'app Heroku mais le CNAME app.example.com pointe toujours vers example.herokuapp.com ? N'importe qui peut enregistrer ce nom d'app et héberger son contenu sur votre sous-domaine. Auditez et supprimez les CNAME orphelins.
Pas d'enregistrement CAA. Sans enregistrement CAA, n'importe quelle CA dans le WebPKI (~50 dans le monde) peut émettre un certificat pour votre domaine. Verrouillez-le à une ou deux CA de confiance : 0 issue "letsencrypt.org". Vérification CA obligatoire depuis septembre 2017.
Enregistrements wildcard masquant des entrées manquantes. Un enregistrement A *.example.com fait que chaque faute de frappe de sous-domaine se résout, cachant de vraies erreurs de configuration. Combinez soigneusement avec des règles MX explicites pour éviter le spam vers les adresses avec faute de frappe.
Mélanger DNSSEC et zones non signées pendant la transition. Activer DNSSEC chez le registrar avant que les nouveaux serveurs de noms ne servent des enregistrements signés produit un SERVFAIL pour chaque résolveur de validation (Cloudflare 1.1.1.1, Quad9). Signez toujours d'abord, puis publiez l'enregistrement DS.

Autres questions fréquemment posées

Pourquoi cet outil renvoie-t-il parfois des résultats différents de dig ?

Deux raisons principales. Premièrement, cet outil interroge via DNS sur HTTPS à travers le résolveur 1.1.1.1 de Cloudflare, tandis que dig sur votre ordinateur portable interroge le résolveur configuré (souvent votre FAI). Différents résolveurs mettent en cache pour différentes durées et peuvent avoir des données obsolètes. Deuxièmement, EDNS Client Subnet (ECS, RFC 7871) envoie un indice sur votre réseau aux serveurs autoritatifs, qui peuvent renvoyer des réponses GeoDNS adaptées ; Cloudflare 1.1.1.1 supprime explicitement ECS pour la confidentialité, donc le géo-ciblage vous voit comme «venant de Cloudflare» plutôt que de votre vraie localisation. dig +short sur un FAI résidentiel verra souvent le résultat personnalisé GeoDNS.

Quelle est la différence entre résolveurs autoritatifs et récursifs ?

Les résolveurs autoritatifs détiennent la copie maître d'une zone (Cloudflare DNS, Route 53, DigitalOcean DNS, etc.) et ne répondent que pour les domaines pour lesquels ils sont configurés. Les résolveurs récursifs (1.1.1.1, 8.8.8.8, votre FAI) prennent les requêtes des clients et parcourent l'arbre DNS en leur nom : root → TLD → autoritatif. Ils mettent en cache les réponses jusqu'au TTL, c'est pourquoi un changement d'enregistrement peut prendre du temps à «se propager». Cet outil parle à un résolveur récursif (Cloudflare 1.1.1.1), donc la réponse que vous voyez est la vue en cache que ce résolveur récursif détient actuellement.

Combien de temps prend réellement la propagation DNS ?

«Propagation» est un faux ami : le DNS ne pousse pas les mises à jour, les résolveurs récursifs du monde entier gardent simplement des copies en cache jusqu'à expiration de leur TTL. Si votre enregistrement A existant avait un TTL de 300 secondes, chaque cache se rafraîchira en 5 minutes. S'il était 86400 (24 heures, un défaut courant), le pire des cas est 24 heures. Certains résolveurs mal-comportés ignorent le TTL et mettent en cache plus longtemps ; certains navigateurs et OS trop empressés mettent en cache localement aussi (le cache DNS interne de Chrome dure 1 minute). Baissez le TTL avant un changement planifié, puis remontez-le après.

Le DNS sur HTTPS est-il vraiment «privé» ?

Il cache les requêtes à votre FAI et aux observateurs sur le chemin sur Wi-Fi, mais le résolveur que vous choisissez peut toujours voir chaque requête. La confiance se déplace de votre FAI à celui qui exploite le point de terminaison DoH (Cloudflare, Google, Quad9, NextDNS). Certains, comme Cloudflare 1.1.1.1, publient des audits indépendants de leur politique no-logs ; d'autres non. DoH ne cache pas non plus l'adresse IP à laquelle vous vous connectez finalement, le champ SNI de votre handshake TLS suivant révèle le domaine de destination aux observateurs réseau, jusqu'à ce que ECH (Encrypted Client Hello, RFC 9180) soit universellement déployé. En 2024, ECH est supporté par Cloudflare, Firefox, Chrome (derrière un flag) mais pas encore omniprésent.

Pourquoi ai-je besoin d'une connexion réseau si c'est un outil «basé navigateur» ?

L'interface fonctionne entièrement dans votre navigateur (pas de code propriétaire sur notre serveur), mais la recherche DNS elle-même est par définition une opération réseau : elle interroge un serveur de noms autoritatif ou récursif distant. Cet outil envoie une seule requête HTTPS par recherche au point de terminaison DoH public 1.1.1.1 de Cloudflare à cloudflare-dns.com/dns-query. Le domaine que vous interrogez est visible par Cloudflare ; rien d'autre (pas d'IP, pas d'empreinte) n'est envoyé.