10 requêtes DNS essentielles résolues avec DIG
Le DNS est mon pain 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.
Tout au long de ce guide, j'utilise +short pour une sortie plus lisible. Quand vous avez besoin du tableau complet, retirez-le.
1. Trouver l'adresse IP d'un domaine
dig +short amazon.com
72.21.211.176
72.21.214.128
72.21.194.1
Plusieurs IP signifient du DNS Round Robin — les clients en choisissent une au hasard. Les enregistrements sont mis en cache pendant 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
Essentiel avant toute migration DNS. Vérifiez 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. Utilisez ceci quand vous suspectez un problème de délégation.
dig google.com +trace
La sortie montre chaque étape : serveurs racine → serveurs TLD .com → propres serveurs de noms de Google. Si quelque chose casse dans la chaîne, c'est ici que vous le trouvez.
4. Trouver les serveurs de messagerie 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é plus bas = préférence plus élevée. Les enregistrements MX doivent pointer vers des enregistrements A, pas des CNAME (RFC 2181 §10.3). Une requête MX sur un domaine ne retournera pas de résultats pour ses sous-domaines.
5. Recherche DNS inversée
Les enregistrements PTR associent des IP à des noms d'hôtes. Essentiels 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 enregistrements PTR sont contrôlés par le propriétaire de l'IP, pas le propriétaire du domaine. Si le DNS inversé n'est pas configuré, vous n'obtiendrez 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 pour déboguer les 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
@ vous permet de cibler n'importe quel résolveur ou serveur de noms directement. Utile pour comparer les résultats en cache avec la sortie autoritaire, ou tester une nouvelle configuration avant la bascule.
dig google.com @8.8.8.8
Comparez la réponse que vous obtenez du résolveur public de Google avec ce que votre FAI retourne. Les différences révèlent des problèmes de cache ou de propagation.
8. Vérifier quand un enregistrement expire 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
Comparez les numéros de série SOA entre tous les serveurs de noms autoritaires. Même numéro de série partout = synchronisé. Différence = 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 numéros de série doivent correspondre :
dig google.com +nssearch | awk '{print $4}' | sort | uniq -c
4 2011120502
Quatre serveurs de noms, un seul numéro de série. La zone est saine.
10. Vérifier si une zone existe sur un serveur de noms
Regardez l'en-tête de statut, 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 concluez pas à partir de réponses vides — lisez toujours le code de statut.
Les problèmes DNS se résument presque toujours à trois choses : mauvais enregistrement, mauvais timing de TTL, ou un trou dans la délégation. Ces dix requêtes couvrent les trois cas.