Dépannage DNS : nslookup, dig, DoH

Problèmes DNS les plus fréquents

• Enregistrement du domaine expiré - tout le DNS cesse de fonctionner.
• Mauvais enregistrement A/AAAA - oublié après une migration de serveur.
• CNAME / MX manquant - le site fonctionne, mais pas l'email.
• TTL non abaissé avant un changement planifié - 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. Il utilise le serveur DNS par défaut du système, mais on peut en spécifier un 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. Il fait 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) = le nombre de secondes pendant lesquelles le resolver peut mettre la réponse en cache.
• ANSWER SECTION = le résultat lui-même.
• SERVER = quel resolver DNS a répondu.
• Query time = durée de la requête - 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, de sorte qu'elles passent partout où le port 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 interface claire est aussi disponible sur /tools/dns-lookup - sans aucune 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 d'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 mettent en cache 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 reste en cache chez certains clients longtemps après le changement. N'éteignez pas l'ancien serveur immédiatement.
• Les cloud providers (Cloudflare, AWS Route 53) prennent en charge des TTL courts et une propagation rapide des changements, 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 la 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 →