Interroger le DNS
dig et nslookup en pratique quotidienne.
Objectifs
À la fin de cette leçon, vous saurez :
- résoudre des noms avec
diget lire sa sortie complète, section par section ; - interroger un serveur DNS précis et comparer les réponses ;
- diagnostiquer les cas classiques : nom inexistant (NXDOMAIN), serveur en panne (SERVFAIL) ;
- utiliser
+shortdans vos scripts.
🔗 Pour vous rafraîchir la mémoire : enregistrements DNS et TTL
La commande de référence : dig
dig example.com
Sortie complète, annotée par bloc :
; <<>> DiG 9.18.10 <<>> example.com ← version + votre question
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; ↑ LE STATUT : NOERROR = tout va bien
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN A ← ce qu'on a demandé
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
↑ TTL restant ← la réponse
;; Query time: 12 msec ← durée de la résolution
;; SERVER: 192.168.65.1#53(192.168.65.1) ← QUI a répondu
;; WHEN: Mon Jan 12 09:14:00 CET 2026
;; MSG SIZE rcvd: 56
Trois zones à lire systématiquement :
- status :
NOERROR(bien),NXDOMAIN(nom inexistant),SERVFAIL(le serveur n'a pas pu répondre — panne en aval) ; - ANSWER SECTION : la valeur + son TTL restant ;
- SERVER : qui a répondu — votre résolveur par défaut, ou celui que vous avez forcé.
Le TTL décroissant : le cache vu en direct
Relancez immédiatement la même commande :
example.com. 3597 IN A 93.184.216.34
3600 → 3597 : le TTL décrémente à chaque interrogation. Ce nombre est le temps de vie RESTANT du ticket de cache chez votre résolveur — vous observez littéralement la mécanique de la leçon précédente. Quand il atteint 0, le résolveur re-demande aux serveurs autoritaires et repart du TTL complet.
Interroger précisément
La syntaxe générale : dig [type] [@serveur] nom.
dig example.com AAAA # chercher l'IPv6 au lieu de l'IPv4
dig www.github.com # suivre un CNAME (visible dans ANSWER)
dig @1.1.1.1 example.com # interroger DIRECTEMENT Cloudflare
dig @8.8.8.8 example.com # ...puis Google, pour comparer
La ligne finale ;; SERVER: confirme toujours qui a réellement répondu — indispensable quand vous croyez interroger X alors que la configuration locale passe par Y.
Pourquoi comparer plusieurs serveurs ? C'est l'outil de vérification d'une migration : après avoir changé un enregistrement A, interrogez plusieurs résolveurs publics — tant que l'un montre encore l'ancienne adresse, son cache n'a pas expiré. Vous mesurez la « propagation » au lieu de la subir.
Version courte : nslookup
nslookup example.com
Server: 192.168.65.1
Address: 192.168.65.1#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
Moins détaillé que dig, mais présent partout, y compris sous Windows (« ça resolve depuis mon poste Windows ? » → nslookup suffit). Notez la mention Non-authoritative : la réponse vient d'un cache, pas du serveur autoritaire — normal et attendu.
Pour le quotidien Linux : préférez dig, plus bavard et scriptable.
Les réflexes de déploiement
Le trio à connaître par cœur avant chaque mise en ligne :
dig monsite.fr +short # juste la valeur : 93.184.216.34
dig monsite.fr MX +short # le courrier pointe-t-il où il faut ?
dig www.monsite.fr CNAME +short # les alias suivent-ils bien ?
+short réduit la sortie à l'essentiel — idéal dans un script :
IP_ACTUELLE=$(dig monsite.fr +short)
[ "$IP_ACTUELLE" = "93.184.216.34" ] && echo "migration visible" || echo "ancienne IP encore en cache"
Vous reconnaissez tous les ingrédients : substitution de commande, code de retour, &&/||. Le DNS devient automatisable comme le reste.
Diagnostiquer les deux pannes classiques
Nom inexistant :
dig nexistepas-exemple-xyz.fr
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
NXDOMAIN (non-existent domain) : le DNS fonctionne parfaitement et affirme que CE NOM n'existe pas. Causes typiques : faute de frappe, domaine non renouvelé, enregistrement jamais créé.
Serveur en panne en aval :
dig monsite-en-panne.fr
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
SERVFAIL : le nom EXISTE mais la chaîne de résolution a échoué — serveurs autoritaires injoignables, zone mal configurée. La distinction NXDOMAIN/SERVFAIL oriente le diagnostic : le premier pointe vers une erreur de configuration du domaine, le second vers une panne technique.
Et le piège local à ne pas oublier : si dig échoue complètement (timeout), vérifiez d'abord VOTRE résolveur (cat /etc/resolv.conf) — parfois le problème n'est ni le domaine ni Internet, mais la configuration DNS locale de la VM.
Exercice
- Résolvez
example.comtrois fois de suite à quelques secondes d'intervalle : notez le TTL à chaque fois. - Comparez les réponses de
@1.1.1.1et de votre résolveur par défaut : mêmes adresses ? mêmes TTL ? Pourquoi ? - Résolvez
github.comen A puis en AAAA. Qu'observez-vous sur les TTL ? - Résolvez un nom inexistant, puis comparez avec un domaine existant dont les serveurs seraient injoignables (ou relisez les exemples du cours). Quelle différence de statut ?
- Écrivez une ligne de shell qui teste si
monsite.frrésout vers93.184.216.34et affiche « ok » / « pas encore propagé ».
Résumé
dig [type] [@serveur] nom: status + ANSWER + SERVER sont les trois lectures obligatoires.- Le TTL affiché décroît : le cache vivant, observable.
+shortpour scripts ; comparaison multi-résolveurs pour mesurer une propagation.- NXDOMAIN ≠ SERVFAIL : nom inexistant vs chaîne cassée.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. Séquence type observée :
3600 → 3594 → 3587 ...
Chaque requête consomme quelques secondes du ticket de cache du résolveur. Si vous voyez au contraire 3600 complet à chaque fois : soit le résolveur re-interroge l'autoritaire (cache désactivé), soit vous changez de résolveur entre deux commandes — les caches ne sont PAS partagés entre résolveurs différents.
Question 2. Mêmes ADRESSES presque toujours (elles viennent in fine du même serveur autoritaire) ; TTL différents quasi sûrs : chaque résolveur a interrogé l'autoritaire à un moment différent, donc ses tickets ont vieilli différemment. C'est exactement pourquoi la « propagation » d'un changement est progressive : chaque cache expire à SON rythme.
Question 3.
$ dig github.com A +short
140.82.121.4
$ dig github.com AAAA +short
140.82.121.3
(TTL variables selon le moment.) Observation instructive : GitHub publie les deux familles — les navigateurs modernes préfèrent l'IPv6 si disponible (AAAA présent), sinon retombent sur A. Un site sans AAAA reste accessible partout, simplement sans v6.
Question 4.
inexistant → status: NXDOMAIN (réponse nette : ce nom n'existe pas)
panne aval → status: SERVFAIL (le nom existe, la chaîne a échoué)
La distinction oriente le diagnostic : NXDOMAIN → vérifier l'orthographe, l'enregistrement, le renouvellement du domaine ; SERVFAIL → vérifier les serveurs autoritaires du domaine (souvent côté fournisseur DNS).
Question 5.
[ "$(dig monsite.fr +short)" = "93.184.216.34" ] && echo "ok" || echo "pas encore propagé"
Ingrédients mobilisés : substitution de commande ($(...)), test de chaîne avec [ ... ], branchement conditionnel. Cette ligne pourrait tourner telle quelle dans un cron de surveillance de migration — le DNS n'a plus aucun secret pour vous, il devient pilotable. Prochaine étape logique : parler AU serveur web lui-même — c'est le protocole HTTP, chapitre suivant.