Comment fonctionne cet outil
Tapez un domaine ou un nom d’hôte, choisissez un type ou laissez ALL, et le serveur lance la requête. Rien à installer, aucun compte.
La recherche est effectuée par le résolveur de notre serveur, du même type que celui de votre système. Pour chaque type, le serveur liste chaque réponse reçue, avec son nom et le TTL restant. Avec ALL, 9 types sont interrogés : A, AAAA, CNAME, MX, NS, TXT, SOA, SRV et CAA.
Si son propre résolveur ne répond pas complètement, le serveur bascule sur une requête DNS-over-HTTPS vers un résolveur public ; ces réponses de secours sont affichées sans TTL. Les résultats sont mis en cache 5 minutes par nom et par type ; le temps de réponse affiché est celui des requêtes en direct, donc très faible pour un résultat en cache.
L’outil accepte les noms en toute casse, retire http:// ou https:// et le chemin d’une URL, et convertit les noms internationalisés en punycode : www.example.com et https://www.example.com/page donnent le même résultat.
Comment lire le résultat
Chaque type a son bloc avec trois colonnes : nom, TTL et valeur, plus le nombre d’enregistrements. Un bloc vide signifie que le nom se résout mais ne publie rien de ce type, ce qui diffère d’un nom inexistant.
Les types d’enregistrement en bref
| Type | Valeur | Usage typique |
|---|---|---|
| A | Adresse IPv4 (32 bits) | Serveurs web ou de messagerie, tout ce qui est joignable en IPv4 |
| AAAA | Adresse IPv6 (128 bits) | Les mêmes services en IPv6 |
| CNAME | Un autre nom dont ce nom est l’alias | Pointer www vers un CDN ou une plateforme d’hébergement |
| MX | Priorité plus nom d’hôte d’un serveur de messagerie | Où le courrier du domaine est livré |
| NS | Nom d’hôte d’un serveur de noms | Quels serveurs font autorité pour la zone |
| TXT | Texte libre | Politiques SPF, clés DKIM, politiques DMARC, vérification de propriété |
| SOA | Serveur primaire, boîte responsable, numéro de série | Administration et réplication de la zone |
| SRV | Priorité, poids, port et hôte cible | Découverte de service pour SIP, XMPP, LDAP et similaires |
| CAA | Drapeaux, étiquette et valeur | Quelles autorités de certification peuvent émettre pour le domaine |
Les valeurs A et AAAA renvoient vers la recherche IP ; les cibles CNAME, NS et MX renvoient vers cet outil, pour suivre une chaîne d’alias ou inspecter un serveur de messagerie.
Les MX portent une priorité : les plus basses sont essayées en premier, deux serveurs de même priorité se partagent la charge ; un domaine publie souvent 2 à 5 MX. Le SOA montre 3 champs : serveur primaire, boîte responsable (point à la place de l’arobase) et numéro de série, incrémenté à chaque modification ; comparer les séries entre serveurs dit s’ils sont synchronisés.
La colonne TTL
Le TTL est le nombre de secondes pendant lesquelles un résolveur peut garder une réponse. La valeur ici est le temps restant dans notre cache, pas le nombre configuré dans la zone : deux recherches à une minute d’intervalle montrent environ 60 secondes de moins, et à zéro le résolveur récupère une copie fraîche. L’entrée TTL du glossaire explique l’effet sur vos modifications.
Du domaine à l’IP et du nom d’hôte à l’IP
Choisissez A pour l’IPv4 ou AAAA pour l’IPv6. Un nom peut en avoir plusieurs ; les navigateurs en choisissent une et se rabattent sur les autres en cas d’échec.
Si le bloc A est vide mais qu’il y a un CNAME, le nom est un alias : cliquez sur la cible pour suivre la chaîne jusqu’à de vrais A ou AAAA. Les longues chaînes ajoutent de la latence, d’où 1 ou 2 sauts chez la plupart des fournisseurs.
D’une adresse vers un nom, utilisez la recherche DNS inverse. Direct et inverse sont gérés séparément ; le nom d’hôte renvoyé n’est pas forcément celui dont vous êtes parti.
Comment corriger les problèmes DNS courants
L’IP est fausse ou obsolète
- Confirmez ce que disent les serveurs autoritaires : recherchez les NS ici, puis interrogez l’un d’eux depuis votre ordinateur (commandes ci-dessous). Si la réponse autoritaire est correcte, l’ancienne adresse vue ailleurs est une copie en cache qui expirera d’elle-même.
- Le vérificateur de propagation DNS montre combien de grands résolveurs publics renvoient déjà la nouvelle valeur.
- Si la réponse autoritaire est fausse, corrigez l’enregistrement là où la zone est hébergée (registrar, fournisseur DNS ou hébergeur), puis attendez l’expiration du TTL.
- Avant le prochain changement, abaissez le TTL à 300 secondes un jour à l’avance.
Pas de MX ou courrier qui n’arrive pas
- Interrogez MX. Bloc vide : les serveurs se rabattent sur l’enregistrement A du domaine, rarement voulu.
- Chaque cible MX doit être un nom d’hôte, pas une IP, avec son propre A ou AAAA ; un MX vers un CNAME viole le standard et certains expéditeurs le rejettent.
- Le serveur principal doit avoir la priorité la plus basse.
- Vérifiez les TXT pour une politique SPF ; un SPF manquant ou cassé envoie souvent le courrier en indésirables.
TXT manquants ou non validés
- Les TXT sont renvoyés tels que publiés : cherchez guillemets parasites, doublons ou mauvais nom (DMARC vit sur
_dmarc.example.com, pas à la racine). - Les sélecteurs DKIM vivent sur
selecteur._domainkey.example.com: saisissez ce nom complet. - Correct côté autoritaire mais ancien ici : le cache n’a pas expiré ; revérifiez après le TTL.
Un CNAME à la racine du domaine
Le standard n’autorise pas de CNAME à l’apex à côté des SOA et NS. Pour pointer le domaine nu vers un nom d’hôte, utilisez la fonction ALIAS, ANAME ou d’aplatissement du fournisseur, ou des A et AAAA ; un CNAME à la racine échoue chez certains résolveurs.
Quel type d’enregistrement répond à quelle question
| Symptôme ou question | Requête | Ce qu’il faut regarder |
|---|---|---|
| Le site ne charge pas | A et AAAA | L’adresse attendue ? Un AAAA vers un hôte sans IPv6 fonctionnel ? |
| Le courrier rebondit ou n’arrive pas | MX, puis A de chaque cible | Au moins un MX, des cibles qui se résolvent, des priorités sensées |
| Le courrier part en indésirables | TXT à la racine, _dmarc et le sélecteur DKIM |
Un seul SPF, une politique DMARC, une clé DKIM pour le sélecteur utilisé |
| Vérification de propriété demandée | TXT au nom indiqué | Le jeton exact, sans guillemets en trop |
| Les changements n’apparaissent pas | NS et SOA | Les NS sont-ils les serveurs modifiés ? La série SOA a-t-elle changé ? |
| Une autorité de certification refuse d’émettre | CAA | Un enregistrement nommant votre AC, ou aucun CAA |
| Une application ne trouve pas son service | SRV sur _service._proto.example.com |
Port et hôte cible |
Un AAAA obsolète est une cause fréquente et discrète de connexions lentes : sur un réseau IPv6, les navigateurs essaient d’abord l’AAAA et attendent un délai avant de retomber sur IPv4. Sans IPv6 sur le serveur, pas d’AAAA.
Ce que disent NS et SOA
Les NS renvoyés viennent de la zone elle-même ; la délégation dans la zone parente (les serveurs .com) peut lister d’autres serveurs. En cas de désaccord, les changements semblent ne s’appliquer qu’une partie du temps ; +trace ci-dessous l’expose. Second contrôle, la série SOA : un secondaire avec une série plus basse n’a pas reçu le dernier transfert de zone.
Vérifier le DNS depuis votre ordinateur
Pour voir ce que renvoie votre résolveur ou un serveur de noms précis :
Windows (invite de commandes) : nslookup -type=MX example.com interroge votre résolveur ; ajoutez un serveur à la fin pour en viser un : nslookup -type=A example.com 1.1.1.1.
Windows (PowerShell) : Resolve-DnsName example.com -Type TXT -Server 8.8.8.8 renvoie un résultat structuré.
macOS et Linux : dig example.com MX +short donne une réponse compacte, dig @ns1.example.net example.com A interroge un serveur autoritaire précis, et dig +trace example.com descend la délégation depuis les serveurs racine.
Pour vider une réponse périmée : ipconfig /flushdns (Windows), sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (macOS), sudo resolvectl flush-caches (Linux avec systemd-resolved). Les navigateurs Chromium ont leur propre cache, sur chrome://net-internals/#dns.
Limites de cet outil
- Les réponses viennent d’un seul résolveur, là où est notre serveur. Un résolveur ailleurs peut avoir une autre copie en cache, et les services à DNS géographique renvoient volontairement d’autres adresses selon le lieu. Aucun outil ne montre la réponse du résolveur de votre FAI.
- Le TTL affiché est le temps restant dans notre cache, pas la valeur configurée.
- Résultats en cache 5 minutes.
- 9 types interrogés ; DNSKEY, DS, TLSA, NAPTR et HINFO ne sont pas couverts, ni le statut DNSSEC.
- Avec le résolveur de secours, pas de TTL et ordre des enregistrements variable.
- La recherche ne teste pas si le serveur fonctionne ; voyez le vérificateur de port.
- Requêtes limitées par visiteur ; les requêtes en masse par script sont refusées.
Rien ici ne dit si votre propre connexion laisse fuir des requêtes DNS hors d’un VPN ou d’un proxy : c’est le rôle du test de fuite DNS.