Dépannage DNS : nslookup, dig, DoH

En bref : Les problèmes DNS sont parmi les causes de pannes les plus fréquentes et les plus difficiles à diagnostiquer - parce que "le DNS marche chez moi" ne signifie pas qu'il marche chez vos clients. Voici un aperçu des outils et procédures pratiques.

Problèmes DNS les plus fréquents

• Enregistrement du domaine expiré - tout le DNS cesse de fonctionner.
• Mauvais enregistrement A/AAAA - oublié de mettre à jour après migration du serveur.
• CNAME / MX manquant - l'email ne fonctionne pas alors que le web oui.
• TTL non préparé pour des changements rapides - les caches des providers servent encore les anciennes données.
• Erreur DNSSEC - les validateurs rejettent les enregistrements non signés ou mal signés.
• Panne Geo-DNS - le resolver d'une région donnée reçoit une mauvaise réponse.

nslookup : la commande la plus simple

Disponible sur tous les OS sans installation. Utilise le serveur DNS par défaut du système, mais on peut le spécifier explicitement en deuxième argument.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Utiliser explicitement Cloudflare DNS
$ nslookup epulz.io 1.1.1.1

# Type d'enregistrement spécifique
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig : requête DNS détaillée pour Unix

dig (Domain Information Groper) est significativement plus détaillé et flexible. Partie du paquet bind-utils ou dnsutils.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Champs clés :

• TTL (300) = secondes pendant lesquelles le resolver peut cacher la réponse.
• ANSWER SECTION = le résultat.
• SERVER = quel resolver DNS a répondu.
• Query time = durée - utile pour déboguer un DNS lent.

Commandes pratiques

# Réponse concise (uniquement IP)
$ dig +short epulz.io
87.197.115.180

# Tous les enregistrements
$ dig epulz.io ANY

# Trace de toute la hiérarchie DNS (depuis les root nameservers)
$ dig +trace epulz.io

# Reverse lookup
$ dig -x 87.197.115.180

# Resolver spécifique
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# Validation DNSSEC
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH) : quand vous n'avez pas UDP/53

Dans certains réseaux (firewalls d'entreprise, données mobiles avec blocage) le port DNS traditionnel 53 est bloqué. DoH emballe les requêtes DNS dans des requêtes HTTPS - elles passent partout où 443 fonctionne.

# Endpoint DoH Cloudflare
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

Un client DoH en ligne avec une jolie UI se trouve aussi sur - pas d'installation.

Procédure en cas de "le domaine ne fonctionne pas"

1. Vérifiez l'enregistrement. whois yourdomain.com ou via le registrar. S'il a expiré, rien d'autre ne peut être réparé.
2. Vérifiez les enregistrements NS. dig NS yourdomain.com @8.8.8.8. Les nameservers responsables du domaine sont-ils renvoyés ? Correspondent-ils à ce que vous avez dans le panel du registrar ?
3. Vérifiez l'enregistrement A. dig yourdomain.com @8.8.8.8. Renvoie-t-il la bonne IP ?
4. Testez depuis un réseau externe (données mobiles, VPN, outil en ligne). Vous-même avez peut-être des anciennes données en cache.
5. Vérifiez le TTL. Si vous venez de changer un enregistrement, attendez au moins le TTL original (1-24 heures par défaut).
6. Vérifiez DNSSEC. Si vous l'utilisez, la chaîne de signatures peut être cassée. dig +dnssec yourdomain.com affiche le flag ad en cas de succès.

Propagation DNS : combien de temps ça prend ?

"Propagation DNS" est un terme un peu trompeur. Le DNS ne se propage pas vers vous - vos resolvers téléchargent la réponse et la cachent selon le TTL. Ce n'est qu'après expiration du TTL qu'ils tentent une nouvelle requête.

Conséquences pratiques :

• Vous planifiez une migration ? Baissez le TTL à 60-300 secondes au moins 48 heures à l'avance.
• L'ancienne IP restera valide pour certains clients longtemps après le changement. N'éteignez pas l'ancien serveur immédiatement.
• Les cloud providers (Cloudflare, AWS Route 53) ont TTL rapide et cache invalidation, mais le client final doit toujours attendre le TTL de son propre resolver.

Conclusion

Le DNS est la colle d'infrastructure que tout le monde prend pour acquise - jusqu'à ce qu'elle cesse de fonctionner. Un monitoring régulier des enregistrements DNS (A, NS, MX, leur TTL et validation DNSSEC) révèle le problème avant qu'un client ne le signale par téléphone.

Monitoring DNS et expiration WHOIS

ePulz.io suit les enregistrements A/AAAA/MX/NS et l'expiration de l'enregistrement du domaine. 7 jours gratuits.

Lancer le monitoring →