Test DNS : comment vérifier une résolution et une zone

Tester son DNS, c’est interroger un serveur précis pour un nom et un type d’enregistrement donnés, puis lire le code retour, les indicateurs et le TTL de la réponse. Une commande dig ou Resolve-DnsName suffit dans la plupart des cas, à condition d’interroger le serveur faisant autorité quand il s’agit de vérifier une modification.

Ce que « tester son DNS » recouvre vraiment

La même requête cache quatre questions différentes. Un développeur qui vient de changer un enregistrement A veut savoir si la zone est correcte chez l’hébergeur. Un indépendant dont le site est injoignable cherche à savoir si la panne vient de son poste ou du domaine. Un administrateur qui compare 1.1.1.1 et 9.9.9.9 veut des millisecondes. Et le « test de fuite DNS » est encore autre chose : il vérifie que votre VPN n’envoie pas vos requêtes au résolveur du FAI.

Un test lancé depuis votre machine mesure d’abord votre résolveur, pas l’état du domaine. Si ce résolveur a l’ancienne valeur en cache, vous la verrez alors que la zone est déjà à jour chez l’hébergeur. C’est l’erreur d’interprétation la plus fréquente. Pour trancher, interrogez directement le serveur faisant autorité.

Le DNS écoute sur le port 53, en UDP et en TCP. Une réponse UDP dépasse rarement 512 octets sans EDNS0 (RFC 6891) ; au-delà, le serveur positionne l’indicateur tc et le client rejoue la requête en TCP.

Ce que vous cherchez	Le test qui répond	Où le lancer
Le domaine résout-il ?	dig +short exemple.fr	n’importe quel poste
Ma modification est-elle en place ?	dig @ns1.hebergeur.tld exemple.fr A	sur le serveur faisant autorité
Mon résolveur est-il lent ?	dig exemple.fr | grep -i query	comparer deux ou trois résolveurs
Quel résolveur m’est appliqué ?	resolvectl status ou dig @1.1.1.1 id.server CH TXT	poste client

Les commandes qui répondent en trois secondes

dig reste l’outil de référence sous Linux et macOS (paquet bind9-dnsutils ou bind-utils). Windows ne le fournit pas, mais PowerShell propose Resolve-DnsName, nettement plus lisible que nslookup. host et drill font le même travail avec une sortie plus courte.

Une commande à retirer de vos réflexes : dig ANY exemple.fr. Depuis la RFC 8482, un serveur peut répondre par un simple HINFO contenant « RFC8482 » au lieu d’énumérer tous les types. Cloudflare le fait sur ses zones. Une réponse ANY vide ne prouve donc rien du tout.

Commande	Ce qu’elle donne
dig +short exemple.fr A	l’adresse IPv4, sans le reste
dig @ns1.hebergeur.tld exemple.fr A +norecurse	la valeur telle que la sert l’autoritaire, sans passer par un cache
dig exemple.fr MX +noall +answer	les serveurs de messagerie et leurs priorités
dig _dmarc.exemple.fr TXT	la politique DMARC réellement publiée
dig +trace exemple.fr	le parcours depuis la racine jusqu’à la zone, sans récursion
dig +nssearch exemple.fr	le numéro de série SOA de chaque serveur autoritaire
Resolve-DnsName exemple.fr -Type A -Server 1.1.1.1	l’équivalent Windows, avec résolveur imposé

Lire la réponse : RCODE, indicateurs et TTL

La ligne qui compte dans une sortie dig commence par « ;; ->>HEADER<<- ». Elle contient le code retour et le nombre d’enregistrements renvoyés. Beaucoup de diagnostics s’arrêtent là.

Le test du TTL vaut le détour : lancez deux fois la même requête à dix secondes d’intervalle. Si le TTL affiché passe de 3600 à 3590, la réponse sort du cache de votre résolveur. S’il repart à 3600 à chaque fois, vous parlez à un autoritaire, ou le cache vient d’expirer.

• aa : la réponse vient d’un serveur faisant autorité sur la zone
• ra : le serveur accepte la récursion pour vous
• ad : la réponse a été validée par DNSSEC
• tc : réponse tronquée, dig rejoue la requête en TCP sur le port 53

Code retour	Interprétation
NOERROR (0)	réponse valide ; vérifiez ANSWER: n, car un 0 signifie que le nom existe mais sans enregistrement du type demandé
SERVFAIL (2)	le résolveur n’a pas obtenu de réponse exploitable : DNSSEC en échec, autoritaires injoignables
NXDOMAIN (3)	le nom n’existe pas dans la zone
REFUSED (5)	le serveur interrogé refuse de répondre pour ce domaine, souvent une IP qui n’est plus autoritaire

Après une modification : ce qui se passe réellement

Rien ne « se propage ». La zone change à un instant précis chez l’hébergeur, et les résolveurs du monde entier continuent de servir l’ancienne valeur jusqu’à expiration de leur copie en cache. Le délai maximal, c’est le TTL publié avant le changement, pas celui que vous publiez après.

D’où la manœuvre classique avant une migration : abaisser le TTL à 300 secondes au moins 24 heures à l’avance, basculer, puis remonter le TTL une fois la bascule stabilisée. Si vous abaissez le TTL le jour même, vous subissez encore l’ancienne valeur.

Un nom qui n’existait pas encore obéit à une autre règle. Un NXDOMAIN est mis en cache selon le champ MINIMUM du SOA, plafonné par le TTL du SOA (RFC 2308). Avec un MINIMUM à 86400, un sous-domaine créé à l’instant peut rester introuvable pendant 24 heures chez ceux qui l’ont demandé trop tôt, même si son propre TTL est à 60.

Les vérificateurs en ligne interrogent une liste de résolveurs publics répartis géographiquement. Leur couverture varie d’un service à l’autre et aucun ne reflète ce que voit un visiteur précis : ils donnent une tendance, pas une preuve. Pour la structure de la délégation elle-même, Zonemaster et DNSViz sont plus parlants qu’un tableau de pastilles vertes.

• Windows : ipconfig /flushdns
• macOS : sudo dscacheutil -flushcache puis sudo killall -HUP mDNSResponder
• Linux avec systemd-resolved : sudo resolvectl flush-caches
• Chrome : chrome://net-internals/#dns, bouton Clear host cache (le navigateur garde son propre cache, indépendant de l’OS)

Cinq pannes que le test permet d’isoler

SERVFAIL sur un domaine qui fonctionne ailleurs. Relancez avec l’option +cd, qui désactive la validation. Si la réponse arrive, le problème est DNSSEC : après une rotation de clé mal terminée, l’enregistrement DS publié chez le registre ne correspond plus à la DNSKEY de la zone, et tous les résolveurs validants renvoient SERVFAIL pendant que les autres servent le site normalement. dnsviz.net dessine la chaîne et montre le maillon cassé.

Sur Ubuntu et Debian récents, /etc/resolv.conf pointe vers 127.0.0.53, le stub de systemd-resolved. Un dig sans @ interroge donc ce cache local, pas votre FAI. resolvectl status donne les serveurs réellement utilisés en amont, interface par interface.

Sur un Wi-Fi d’hôtel ou un réseau d’entreprise, le port 53 sortant est fréquemment redirigé vers le résolveur maison. Un dig @1.1.1.1 qui renvoie autre chose que ce que sert Cloudflare trahit l’interception. Comparez avec du DoT (port 853, RFC 7858) ou du DoH (port 443, RFC 8484) : si le résultat change, quelqu’un réécrit vos réponses en chemin.

Quad9 (9.9.9.9) renvoie NXDOMAIN sur les domaines qu’il classe comme malveillants. Un nom qui répond via 1.1.1.1 mais pas via 9.9.9.9 n’a pas forcément une zone cassée : il peut simplement figurer sur une liste de blocage.

Dernier cas, sournois : le CNAME à l’apex. exemple.fr sans sous-domaine porte déjà un SOA et des NS, et la RFC 1034 interdit qu’un CNAME coexiste avec d’autres enregistrements sur le même nom. Certains hébergeurs contournent avec un ALIAS ou un ANAME résolu côté serveur. Si le panneau de l’hébergeur affiche la bonne cible et qu’un résolveur externe ne renvoie rien, regardez de ce côté.

Questions fréquentes

Comment savoir en une commande si mon domaine résout ?

dig +short exemple.fr renvoie l’adresse et rien d’autre. Sous Windows, Resolve-DnsName exemple.fr. Une sortie vide ne veut pas dire que le domaine est cassé : refaites le test avec dig exemple.fr complet pour lire le code retour, un NXDOMAIN et un NOERROR sans réponse ne se soignent pas de la même façon.

Combien de temps avant que mon changement DNS soit visible partout ?

Au maximum le TTL qui était publié sur l’enregistrement avant la modification. Avec un TTL de 3600, comptez une heure pour les résolveurs qui avaient l’ancienne valeur en cache, moins pour ceux qui n’avaient rien. Les 48 heures souvent citées correspondent aux TTL élevés de certains registres et aux caches de FAI qui ne respectent pas toujours les valeurs annoncées.

dig ou nslookup ?

dig affiche le code retour, les indicateurs, le TTL et le serveur qui a répondu, ce qui permet de diagnostiquer. nslookup masque une partie de ces informations et son mode interactif prête à confusion. Sous Windows, Resolve-DnsName est un meilleur choix que nslookup ; sinon installez dig avec les outils BIND.

Pourquoi dig +trace donne un résultat différent de mon navigateur ?

+trace part des serveurs racine et suit les délégations lui-même, sans passer par votre résolveur ni par aucun cache. Il montre donc ce que servent les autoritaires à cet instant, pas ce que voit un visiteur. L’écart entre les deux est justement la mesure de ce qui reste en cache.

Comment vérifier que mes serveurs autoritaires sont synchronisés ?

dig +nssearch exemple.fr interroge chaque serveur listé dans la délégation et affiche son SOA. Comparez les numéros de série : s’ils diffèrent, un secondaire n’a pas reçu le transfert de zone et sert encore l’ancienne version, ce qui produit des réponses incohérentes selon le serveur tiré au sort par le résolveur.

Testez vos connaissances

À lire aussi

commande dig · cloudflare dns 1 1 1 1 · cache · anycast