Publié le 21 avril 20267 min de lecture

Comment tracer la résolution DNS : Déboguer les recherches avec dig et nslookup

Apprenez à tracer une résolution DNS étape par étape avec dig +trace, nslookup, et drill. Déboguez NXDOMAIN, les recherches lentes, et les problèmes de propagation avec des exemples pratiques.

dnsdns-tracedignetworkingtroubleshooting

Lorsqu'un domaine ne se résout pas, charge lentement, ou renvoie une IP inattendue, la cause principale se trouve presque toujours quelque part dans la chaîne de résolution DNS. Une seule requête contre votre résolveur local masque ce qui s'est réellement passé — quels serveurs de noms ont été interrogés, lesquels ont répondu, et où la chaîne a échoué. Pour voir toute l'histoire, vous avez besoin d'un trace DNS.

Ce guide vous montre comment tracer une résolution DNS de bout en bout en utilisant des outils standards, lire la sortie, et diagnostiquer les modes de défaillance les plus courants.

Qu'est-ce qu'un Trace DNS ?

Un trace DNS est une marche étape par étape dans la résolution récursive d'un nom de domaine, en commençant par les serveurs de noms racine et en suivant la chaîne de délégation jusqu'au serveur de noms autoritaire pour le domaine. Contrairement à une recherche standard qui ne renvoie que la réponse finale, un trace montre chaque requête et réponse intermédiaire, permettant de localiser précisément où une résolution échoue ou se comporte mal.

Comment fonctionne la résolution DNS (Bref aperçu)

Chaque résolution de domaine suit la même hiérarchie :

Serveurs de noms racine (.) — 13 serveurs logiques qui savent quels serveurs de noms gèrent chaque domaine de premier niveau (TLD).
Serveurs de noms TLD (.com, .org, .fr, …) — délèguent aux serveurs de noms autoritaires du domaine enregistré.
Serveurs de noms autoritaires — détiennent les enregistrements réels (A, AAAA, MX, TXT, …) pour le domaine.

Un résolveur récursif (le DNS de votre FAI, 1.1.1.1, 8.8.8.8, Pi-hole, etc.) parcourt cette chaîne en votre nom et met en cache les résultats. Lorsque vous tracez vous-même la résolution, vous contournez le cache et observez le chemin de délégation brut.

Exécuter un Trace DNS avec `dig`

La commande dig (faisant partie de bind-utils sur Linux, bind9-dnsutils sur Debian/Ubuntu, et livrée par défaut sur macOS) est l'outil standard pour le débogage DNS. Son drapeau +trace lance un trace récursif complet depuis la racine :

dig +trace example.com

La sortie liste, pour chaque niveau, les serveurs de noms interrogés et leurs réponses. Un trace typique pour example.com ressemble à ceci :

;; global options: +cmd
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
...
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
...
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 289 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 18 ms

Chaque bloc montre la délégation à ce niveau, le TTL, le serveur de noms qui a répondu, et le temps de requête. Le dernier bloc contient la réponse autoritaire.

Alternatives : `nslookup` et `drill`

nslookup (disponible partout, y compris Windows) est plus simple mais moins flexible. Il ne supporte pas un trace récursif, mais vous pouvez interroger manuellement chaque niveau :

nslookup -type=NS com.
nslookup -type=NS example.com. a.gtld-servers.net
nslookup example.com. a.iana-servers.net

drill (de ldns) est un remplacement moderne pour dig avec une sortie plus claire et un meilleur support DNSSEC :

drill -T example.com

Sur Windows, Resolve-DnsName dans PowerShell est l'équivalent moderne, bien qu'il ne produise pas un trace par lui-même.

Lire la sortie du Trace

Trois champs sont importants lors de l'interprétation d'un trace :

TTL (premier nombre) — combien de temps l'enregistrement peut être mis en cache. Un TTL très faible (moins de 60 s) indique souvent un équilibrage de charge ou un changement récent ; un TTL élevé (24 h+) signifie que les changements se propageront lentement.
Source du serveur de noms (from X.X.X.X#53(nom de l'hôte)) — qui a répondu à chaque étape. Si le même serveur apparaît à plusieurs niveaux, quelque chose est mal configuré.
Temps de requête (in N ms) — latence vers chaque serveur de noms. Un seul saut lent peut ajouter des centaines de millisecondes à chaque résolution non mise en cache.

Problèmes DNS courants et comment les repérer

NXDOMAIN — le serveur de noms autoritaire renvoie "nom n'existe pas". Vérifiez les fautes de frappe, les domaines expirés, ou une délégation incorrecte au niveau du TLD.
SERVFAIL — un serveur de noms dans la chaîne est inaccessible ou renvoie des réponses malformées. Faites deux fois le trace : si le serveur défaillant change, le problème est transitoire ; s'il reste le même, le problème vient de ce serveur spécifique.
Résolution lente — regardez les temps de requête par niveau. Une requête lente au niveau racine ou TLD est rare et suggère des problèmes de réseau local. Une requête lente vers le serveur autoritaire indique un problème chez l'opérateur du domaine.
Données obsolètes — si un trace montre la bonne IP mais que votre navigateur utilise une ancienne, votre résolveur récursif met encore en cache. Videz le cache avec sudo resolvectl flush-caches (systemd-resolved), sudo dscacheutil -flushcache (macOS), ou ipconfig /flushdns (Windows).
Problèmes de propagation — après un changement DNS, différents résolveurs voient des valeurs différentes jusqu'à l'expiration des TTL. Interrogez plusieurs résolveurs publics (1.1.1.1, 8.8.8.8, 9.9.9.9) pour vérifier la cohérence.
Délégation défaillante — un TLD délègue à des serveurs de noms qui ne répondent pas de manière autoritaire pour la zone. Visible comme un SERVFAIL de la part de un ou plusieurs serveurs alors que d'autres fonctionnent.

Trace DNS vs Recherche DNS : Connaître la différence

Un simple dig example.com interroge votre résolveur récursif, renvoie la réponse mise en cache, et ne vous dit rien du chemin. Un trace contourne le cache et parcourt la chaîne lui-même. Utilisez une recherche pour vérifier le résultat ; utilisez un trace pour déboguer le processus.

Quand le trace ne suffit pas

DNS n'est qu'une moitié de la connexion. Une fois qu'un nom est résolu, vos paquets doivent encore trouver le serveur via des réseaux routés BGP. Si DNS renvoie la bonne IP mais que le service est inaccessible ou lent, lancez un traceroute vers l'adresse résolue pour voir où le chemin réseau échoue. Des outils comme TraceMapper combinent ces deux perspectives : ils résolvent le nom d'hôte, puis visualisent le chemin réseau hop par hop, pour que vous puissiez exclure DNS et vous concentrer sur la véritable route.

Principaux enseignements

Utilisez dig +trace (ou drill -T) pour parcourir toute la chaîne de délégation du racine au serveur de noms autoritaire.
Vérifiez les TTL, les sources des serveurs de noms, et les temps de requête à chaque niveau pour identifier le saut qui dysfonctionne.
NXDOMAIN, SERVFAIL, et les sauts lents indiquent chacun des classes de problème différentes — délégation, santé du serveur de noms, ou latence.
Videz les caches locaux et interrogez plusieurs résolveurs publics lors du diagnostic de problèmes de propagation.
Après avoir exclu un problème DNS, un traceroute sur l'IP résolue complète le tableau diagnostique.