10 requêtes DNS indispensables avec dig

Le DNS, c'est mon quotidien. Neuf ans à construire l'infrastructure d'EuroDNS, gérer des zones, déboguer des échecs de résolution, migrer des serveurs de noms à grande échelle. Voici les dix requêtes dig que j'utilise le plus — celles qui résolvent vraiment les problèmes.

Écran d'ordinateur portable montrant un terminal sombre avec du code vert sur un bureau

Dans tout ce guide, j'utilise +short pour alléger la sortie. Quand il faut le détail complet, on l'enlève.

1. Trouver l'IP d'un domaine

dig +short amazon.com

72.21.211.176
72.21.214.128
72.21.194.1

Plusieurs IP = DNS Round Robin — les clients en choisissent une au hasard. Les enregistrements sont mis en cache pour la durée de leur TTL. Pour cibler un résolveur spécifique : dig +short amazon.com @8.8.8.8.

2. Identifier les serveurs de noms d'un domaine

Indispensable avant toute migration DNS. On vérifie la délégation avant de toucher à quoi que ce soit.

dig NS +short anouar.im

n1.eurodns.com.
n2.eurodns.com.
n3.eurodns.com.
n4.eurodns.com.

Les TTL des enregistrements NS sont généralement longs (24h+). Pendant les migrations, gardez l'ancienne zone active pendant au moins la durée complète du TTL avant de la décommissionner.

3. Tracer le chemin complet de résolution DNS

+trace contourne les caches et parcourt toute la chaîne de délégation — serveurs racine → TLD → autoritaire. À utiliser dès qu'on soupçonne un problème de délégation.

dig google.com +trace

La sortie montre chaque étape : serveurs racine → serveurs TLD .com → serveurs de noms de Google. Si quelque chose casse dans la chaîne, c'est là qu'on le trouve.

4. Trouver les serveurs mail d'un domaine

dig MX adlani.com

adlani.com.  3527  IN  MX  10 aspmx.l.google.com.
adlani.com.  3527  IN  MX  20 alt2.aspmx.l.google.com.
adlani.com.  3527  IN  MX  30 aspmx5.googlemail.com.

Numéro de priorité bas = préférence haute. Les enregistrements MX doivent pointer vers des enregistrements A, pas des CNAME (RFC 2181 §10.3). Une requête MX sur un domaine ne retourne pas de résultats pour ses sous-domaines.

5. Recherche DNS inversée

Les enregistrements PTR associent des IP à des noms d'hôtes. Indispensables pour la réputation e-mail, les vérifications de sécurité, et rendre la sortie de traceroute lisible.

dig +short -x 8.8.8.8

google-public-dns-a.google.com.

Les PTR sont contrôlés par le propriétaire de l'IP, pas celui du domaine. Si le DNS inversé n'est pas configuré, on n'obtient rien — ou pire, le nom d'hôte de quelqu'un d'autre.

6. Trouver les serveurs de noms d'un TLD

Même syntaxe que pour n'importe quel domaine. Utile quand on débogue des problèmes de délégation au niveau du registre.

dig +short NS nl.

nl1.dnsnode.net.
ns1.nic.nl.
ns2.nic.nl.
ns3.nic.nl.

7. Interroger un serveur DNS spécifique

@ permet de cibler n'importe quel résolveur ou serveur de noms directement. Pratique pour comparer les résultats en cache avec la réponse autoritaire, ou pour tester une nouvelle config avant la bascule.

dig google.com @8.8.8.8

Comparez la réponse du résolveur public de Google avec celle de votre FAI. Les écarts révèlent des problèmes de cache ou de propagation.

8. Vérifier quand un enregistrement sort du cache

La colonne TTL indique combien de secondes avant que le résolveur interroge à nouveau.

dig google.com +noall +answer

google.com.  105  IN  A  74.125.79.99
google.com.  105  IN  A  74.125.79.103

105 secondes restantes. Pendant les migrations, je baisse les TTL à 300s (5 min) 24 à 48 heures avant le changement, j'effectue la bascule, puis je les remonte une fois la propagation confirmée.

9. Vérifier la synchronisation de zone entre les serveurs de noms

On compare les numéros de série SOA entre tous les serveurs de noms autoritaires. Même serial partout = synchronisé. Écart = problème de réplication.

dig google.com +nssearch

SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns1.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns2.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns3.google.com
SOA ns1.google.com. dns-admin.google.com. 2011120502 ... from ns4.google.com

Vérification rapide — tous les serials doivent correspondre :

dig google.com +nssearch | awk '{print $4}' | sort | uniq -c

4 2011120502

Quatre serveurs de noms, un seul serial. La zone est saine.

10. Vérifier si une zone existe sur un serveur de noms

C'est l'en-tête de statut qu'il faut lire, pas seulement la section réponse.

NOERROR — la zone existe
NXDOMAIN — le domaine n'existe pas
REFUSED — le serveur de noms refuse de répondre (politique ou non autoritaire)

# Domaine existant
dig SOA google.nl @ns1.nic.nl.
# → status: NOERROR

# Domaine inexistant
dig SOA googleqwerty.nl @ns1.nic.nl.
# → status: NXDOMAIN

# Domaine non géré ici
dig SOA google.com @ns1.nic.nl.
# → status: REFUSED

Ne tirez pas de conclusions d'une réponse vide — lisez toujours le code de statut.

Les problèmes DNS se résument presque toujours à trois choses : mauvais enregistrement, mauvais timing de TTL, ou trou dans la chaîne de délégation. Ces dix requêtes couvrent les trois cas.