DNS lent ? Je teste et je dépanne avec dig et nslookup

DNS lent : quand tout rame "sans raison"

Tu vois le tableau ? Les pages finissent par s'ouvrir, mais la première seconde (ou deux) tu as juste... rien. Comme si Internet hésitait. Et souvent, le coupable n'est pas ton débit, ni ton Wi‑Fi, ni ton PC "fatigué". C'est le DNS. Le truc qui traduit un nom de domaine (ex : google.com) en adresse IP (ex : 142.250.x.x).

La première fois que ça m'a sauté aux yeux, c'était sur une machine Windows "nickel" : speedtest au top, ping stable, mais ouverture de sites pénible. Du coup, j'ai arrêté de soupçonner le navigateur et j'ai commencé à mesurer le DNS. Et là... jackpot : des réponses à 800 ms, parfois des timeouts. Bref, je te montre comment je teste et je dépanne avec dig et nslookup, en mode concret.

Avant de jouer au détective : comprendre ce qu'on mesure

Quand tu tapes un site, ton appareil demande à un résolveur DNS (souvent ta box, ou les DNS de ton FAI, ou un DNS public) : "tu sais où est ce domaine ?". Si ce résolveur répond lentement, tout le reste part avec un handicap.

Le truc à garder en tête : un DNS peut être lent pour plusieurs raisons. Résolveur saturé, route réseau pourrie, box qui fait n'importe quoi, IPv6 qui part en vrille, cache vide, ou même un firewall qui bloque une partie des requêtes.

Personnellement, je préfère toujours mesurer d'abord, avant de changer des DNS "au hasard". Parce que changer pour changer, ça peut masquer le problème sans le régler (et tu retombes dessus plus tard).

Outils : dig vs nslookup (et comment les avoir selon ton OS)

dig : mon préféré pour diagnostiquer

dig (Domain Information Groper) est ultra pratique : il affiche les temps, les serveurs interrogés, et tu peux le rendre bavard ou au contraire très minimal. Sur Linux/macOS, c'est souvent déjà là. Sur Windows, pas par défaut (sauf environnements type WSL).

nslookup : disponible presque partout

nslookup est l'outil "classique" sur Windows, et il fait largement le job pour comparer des serveurs DNS et repérer une latence bizarre. Je l'utilise quand je suis sur une machine où je n'ai pas envie d'installer quoi que ce soit.

Installer dig rapidement (si tu es sur Windows)

Bon, soyons honnêtes : sur Windows, le moyen le plus simple que j'utilise, c'est WSL (Ubuntu) et ensuite un petit apt install dnsutils. Sinon, tu peux aussi passer par Git for Windows (qui apporte parfois des outils), ou installer BIND tools, mais WSL reste le plus clean si tu l'as déjà.

Étape 1 : identifier le DNS utilisé par ta machine

Question bête, mais si tu testes le mauvais serveur, tu pars dans le décor. Avant tout, je regarde quel DNS est configuré.

Sur Windows

Dans un terminal (PowerShell ou CMD) :

ipconfig /all

Repère la carte réseau active et la ligne "Serveurs DNS". Si tu vois l'IP de ta box (souvent 192.168.1.1), ça veut dire que ta box sert de résolveur (ou de relais vers le FAI).

Sur macOS / Linux

Sur macOS, je jette un œil avec :

scutil --dns

Sur Linux, selon les distros :

resolvectl status (systemd-resolved) ou cat /etc/resolv.conf (à interpréter selon le setup).

Étape 2 : tester vite fait avec nslookup (comparaison immédiate)

Quand je veux un verdict rapide, je compare plusieurs DNS sur le même nom de domaine. L'idée : si ton DNS "habituel" met 600 ms et que Cloudflare répond en 20 ms, tu as déjà une piste.

Test simple

Dans un terminal :

nslookup google.com

Tu verras le serveur DNS utilisé et la réponse. Répète 2-3 fois. Si une fois sur deux tu as un timeout, ça sent mauvais.

Forcer un serveur DNS précis

Exemples :

nslookup google.com 1.1.1.1 (Cloudflare)
nslookup google.com 8.8.8.8 (Google)
nslookup google.com 9.9.9.9 (Quad9)

Après avoir testé, je note surtout : est-ce que ça répond à chaque fois ? et est-ce que ça met "une éternité" ? nslookup ne donne pas toujours un timing hyper clair, mais tu sens vite si ça traîne.

Étape 3 : mesurer proprement avec dig (et sortir le chrono)

Si tu as dig, là tu peux faire les choses proprement. Ce que je veux : le temps de requête et la stabilité.

Commande de base

dig google.com

Dans la sortie, repère la ligne :

Query time: XX msec

Franchement, au-delà de 100-150 ms en usage courant, je commence à lever un sourcil (ça dépend d'où tu es et du serveur, mais tu vois l'idée). À 300-800 ms, je considère que ça va se sentir à l'ouverture des sites.

Tester un DNS spécifique

dig @1.1.1.1 google.com
dig @8.8.8.8 google.com
dig @9.9.9.9 google.com

Le but n'est pas de "choisir le meilleur sur le papier". Le but c'est de voir lequel répond vite depuis chez toi, sur ton réseau, maintenant.

Sortie minimale (pour aller vite)

Quand je veux juste la réponse + le temps :

dig @1.1.1.1 google.com +noall +answer +stats

Ça évite de scroller comme un malade et tu vois tout de suite si le temps explose.

Tester un enregistrement précis (A / AAAA)

Parfois, le souci vient d'IPv6 (AAAA) qui met du temps ou part en timeout, et du coup ton système "attend" avant de basculer en IPv4. Pour vérifier :

dig @1.1.1.1 google.com A +stats
dig @1.1.1.1 google.com AAAA +stats

Après avoir testé ça sur un réseau un peu bancal, j'ai déjà vu des AAAA répondre beaucoup plus lentement que les A. Résultat : impression de lenteur alors que l'IPv4 est OK.

Étape 4 : repérer si le cache te ment (ou te rassure trop)

Un piège classique : tu fais un test, ça répond super vite... parce que c'est déjà en cache. Et deux minutes plus tard, sur un autre domaine, ça retombe dans la boue.

Moi, je teste toujours :

• un domaine très connu (google.com) pour avoir une base
• un domaine moins fréquent (un petit site) pour forcer des résolutions "moins chaudes"
• plusieurs fois d'affilée pour voir la stabilité

Si le premier test est lent puis les suivants rapides, c'est normal (cache). Si c'est aléatoire, là tu tiens un vrai problème.

Étape 5 : diagnostiquer la panne avec une méthode simple (celle que j'utilise)

Quand ça rame, je procède toujours dans cet ordre. Pas parce que c'est "académique", juste parce que ça évite de partir dans tous les sens.

1. Je teste le DNS actuel (souvent la box) : timeouts ? latence énorme ?
2. Je teste un DNS public (1.1.1.1 / 8.8.8.8 / 9.9.9.9) : si c'est nickel, le souci est côté box/FAI/réseau local.
3. Je compare A vs AAAA : si AAAA est catastrophique, je suspecte IPv6.
4. Je teste plusieurs domaines : si un seul domaine pose souci, c'est peut-être le domaine/zone DNS, pas ton réseau.

À ce stade, tu sais généralement "où" ça casse : chez toi (box), chez le FAI, ou sur un domaine précis.

Solutions concrètes quand tu as confirmé un DNS lent

1) Contourner la box en mettant un DNS public

Si ta box fait relais DNS et qu'elle est lente (ça arrive), tu peux configurer ton PC ou ton smartphone avec un DNS public. Perso, je teste d'abord en local sur un seul appareil, histoire de valider que ça change vraiment quelque chose.

DNS populaires :

Cloudflare : 1.1.1.1 / 1.0.0.1
Google : 8.8.8.8 / 8.8.4.4
Quad9 : 9.9.9.9 / 149.112.112.112

Honnêtement, si tu veux juste "que ça marche vite", Cloudflare marche souvent très bien. Si tu veux un filtre sécurité (blocage de domaines malveillants), Quad9 peut être intéressant. Mais je ne choisis jamais sans mesurer chez moi.

2) Tester DoH/DoT (si ton environnement le supporte)

Selon ton OS et ton navigateur, tu peux activer le DNS chiffré (DoH/DoT). Ça peut améliorer la confidentialité, parfois la stabilité... mais ça peut aussi compliquer le dépannage si ton réseau d'entreprise n'aime pas ça. Chez moi, je l'active surtout sur mobile et sur certains navigateurs, mais je garde en tête que ça peut changer le chemin réseau.

3) Si IPv6 est la source de lenteur

Si tes tests montrent un AAAA lent ou instable, tu as plusieurs options. La plus propre : corriger l'IPv6 (routeur/FAI). La plus pragmatique, quand tu veux juste bosser : désactiver IPv6 sur l'interface réseau ou sur la box, temporairement, pour confirmer.

Je te le dis comme je le fais : je désactive pour tester, je valide que ça règle le symptôme, puis je cherche la vraie cause. Parce que couper IPv6 "pour toujours", ça dépanne, mais c'est un pansement.

4) Redémarrer/mettre à jour la box (oui, parfois c'est juste ça)

Ça fait cliché, mais j'ai déjà vu des boxes partir en sucette sur la partie DNS après des semaines d'uptime. Redémarrage, firmware à jour, et hop. Si ton DNS configuré est l'IP de la box, ça vaut le coup d'essayer.

Mini check-list : quand je considère que le DNS est "OK"

Je ne cherche pas le score parfait. Je cherche un usage fluide. En gros, quand :

• les requêtes répondent sans timeout
• les temps restent stables (pas 20 ms puis 900 ms au hasard)
• A et AAAA sont cohérents (ou au moins AAAA ne plombe pas tout)

Si tu coches ça, tu peux arrêter de suspecter le DNS et regarder ailleurs (proxy, MTU, Wi‑Fi, congestion, etc.).

Conclusion : mesure, compare, et tu sauras quoi changer

Le DNS lent, c'est typiquement le problème "invisible" qui te donne l'impression que tout Internet est mou, alors que ton débit est bon. Avec nslookup tu compares vite fait, avec dig tu mets un chrono et tu vois clair. Après avoir testé comme ça sur plusieurs réseaux, je peux te dire un truc : quand tu as des timeouts ou des latences qui partent en montagnes russes, ce n'est pas "dans ta tête".

Si tu veux, dis-moi : ton OS, le DNS que tu utilises (box/FAI/Cloudflare/etc.) et un ou deux résultats de dig +stats. Je te dirai ce que j'en pense et où ça sent la panne.