Dépanner DNS et DHCP : nslookup, dig, ipconfig, Wireshark

Dépanner un service réseau, c'est suivre le chemin d'une requête, étape par étape, jusqu'à trouver celle qui échoue, en vérifiant chaque hypothèse par une commande plutôt qu'en devinant. Pour DNS et DHCP, une dizaine de commandes suffit : ipconfig, Resolve-DnsName et nslookup sous Windows, ip, dig et getent sous Linux, tcpdump et Wireshark pour voir ce qui passe vraiment sur le réseau. Ce chapitre donne la méthode, les outils, les pièges des outils eux-mêmes et les symptômes types, puis la déroule sur des cas concrets.

La méthode : du bas vers le haut, une hypothèse à la fois

Devant « Internet ne marche pas » ou « l'intranet est inaccessible », la tentation est de redémarrer quelque chose. Résiste. Suis le chemin :

1. Reformuler et délimiter. Qui est touché : un poste, un VLAN, tout le monde ? Depuis quand ? Qu'est-ce qui a changé ? Un seul poste en panne oriente vers le poste ; tout un VLAN, vers ce qui est commun au VLAN (relais, passerelle, étendue) ; tout le monde, vers un serveur.
2. La configuration IP. Le poste a-t-il une adresse, la bonne passerelle, les bons DNS ? (ipconfig /all)
3. La connectivité. La passerelle répond-elle ? Le serveur répond-il par son adresse ? (ping, Test-NetConnection)
4. La résolution de noms. Le nom se résout-il, vers la bonne adresse, auprès du bon serveur ? (Resolve-DnsName, nslookup, dig)
5. Le service. Le port du service répond-il ? (Test-NetConnection -Port, curl)
6. L'application. Le service répond-il correctement ? (journaux, codes HTTP)

À chaque étape, une commande confirme ou élimine une hypothèse. Note ce que tu fais et ce que tu observes : c'est ce qu'on attend de toi en épreuve, et c'est ce qui permet à un collègue de reprendre le dossier (cours ITIL et support).

Les commandes du poste

Le piège des outils : qui résout quoi ?

Les outils de diagnostic ne passent pas tous par le même chemin que les applications.

D'où un grand classique : nslookup intranet.sorbier.example donne la bonne adresse, mais le navigateur va ailleurs. nslookup interroge directement le serveur DNS ; le navigateur, lui, lit d'abord le fichier hosts, où un ancien test a laissé une ligne. Pour savoir ce que voient les applications, utilise Resolve-DnsName (sans -Server) ou getent hosts.

Lire dig et Resolve-DnsName

$ dig @192.168.10.177 intranet.sorbier.example +noall +answer +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50211
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
intranet.sorbier.example. 3600 IN A 192.168.21.10

PS> Resolve-DnsName intranet.sorbier.example -Server 192.168.10.177

Name                          Type   TTL   Section    IPAddress
----                          ----   ---   -------    ---------
intranet.sorbier.example      A      3600  Answer     192.168.21.10

Les options de dig qui servent le plus :

dig +trace www.sorbier.example est l'outil qui répond à « la délégation est-elle correcte ? » : il montre quels serveurs la racine, puis .example, annoncent pour la zone, et ce que ces serveurs répondent.

Côté serveurs

Sous Debian avec BIND : sudo rndc status, sudo rndc zonestatus <zone>, sudo rndc querylog on (journalise chaque requête, à couper ensuite), journalctl -u named. Sur pfSense : Status > DHCP Leases pour les baux distribués, Status > System Logs, onglets DHCP et DNS Resolver.

Capturer pour voir ce qui passe vraiment

Quand les commandes ne suffisent pas, capture le trafic : tu vois si la requête part, si elle arrive, et ce que le serveur répond.

# Sur un serveur Debian : le DHCP, en détail
sudo tcpdump -ni ens18 -vv 'udp port 67 or udp port 68'

# Le DNS, en enregistrant la capture pour l'ouvrir ensuite dans Wireshark
sudo tcpdump -ni ens18 -w /tmp/dns.pcap 'port 53'

# Sous Windows, sans rien installer : pktmon, fourni avec le système
pktmon start --capture --file-name C:\Temp\capture.etl
# ... reproduire le problème ...
pktmon stop
pktmon etl2pcap C:\Temp\capture.etl --out C:\Temp\capture.pcapng

Sur pfSense, Diagnostics > Packet Capture capture sur une interface choisie, avec un filtre sur l'hôte et le port, et propose le fichier au téléchargement.

Dans Wireshark, les filtres d'affichage à connaître :

Les filtres d'affichage (dhcp, dns) ne s'écrivent pas comme les filtres de capture de tcpdump (udp port 67), qui décident de ce qui est enregistré. La lecture d'une capture couche par couche est expliquée dans le chapitre Wireshark du cours Réseaux fondamentaux.

Les symptômes types

Un cas complet

Mardi, 9 h 10. Plusieurs magasiniers de l'entrepôt signalent que leurs terminaux de scan « n'ont plus le réseau ». Les postes des bureaux fonctionnent.

1. Délimiter. Seul le VLAN 30 est touché, depuis ce matin. Hier soir, Moussa Diallo a remplacé le switch de l'entrepôt. Hypothèse : un problème commun au VLAN 30, lié au nouveau switch.
2. Configuration IP. Sur un terminal : adresse 169.254.12.40. Aucune réponse DHCP.
3. Le serveur. Get-DhcpServerv4ScopeStatistics sur srv-ad : l'étendue 192.168.10.128 est active, occupée à 59 %. Le serveur n'est pas en cause.
4. Le relais. Sur SW-COEUR, l'interface Vlan30 porte bien ip helper-address 192.168.10.177 et .181.
5. Le chemin. Une capture sur SW-COEUR ne montre aucun DISCOVER venant du VLAN 30. Les demandes n'arrivent pas jusqu'au relais. Sur le nouveau switch, show interfaces trunk : le lien vers SW-COEUR n'autorise que les VLAN 10 et 99.
6. Correction. switchport trunk allowed vlan add 30 sur le port du trunk ; ipconfig /renew (ou le redémarrage du Wi-Fi des terminaux) : ils reçoivent une adresse en 192.168.10.1xx. Le dossier est documenté : la configuration du switch de remplacement doit être reprise de la sauvegarde de l'ancien (cours Routage et commutation).

L'erreur aurait été de redémarrer le serveur DHCP, ou de recréer l'étendue : ni l'un ni l'autre n'étaient en cause, et la capture l'a prouvé en une minute.

Exercices