Linux / Commande dig : interroger DNS et comprendre les réponses

dig interroge un serveur DNS, Domain Name System, et affiche les enregistrements reçus ainsi que le statut de la réponse. Il sert à examiner une adresse IPv4 ou IPv6, un serveur de courrier ou un texte DNS, et à comparer les réponses de serveurs précis. Pour diagnostiquer un résultat vide, commencez par la sortie complète : +short masque une partie du contexte nécessaire.

Choisir le nom, le type et le serveur

La forme courante de l’outil de BIND 9 est :

dig [@SERVEUR_DNS] NOM [TYPE] [OPTIONS]

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT

A demande les adresses IPv4, AAAA les adresses IPv6, MX les informations de routage du courrier et TXT des données textuelles. Un MX comporte notamment une préférence et le nom d’un échangeur de courrier : une valeur de préférence plus faible est privilégiée. Aucun de ces résultats ne prouve que le service applicatif correspondant fonctionne.

Avec un nom mais sans type explicite, dig demande normalement A. Sans aucun argument, il interroge les serveurs NS de la racine ; ce n’est pas une demande A sur un domaine implicite. La configuration personnelle ~/.digrc peut modifier des options ; -r permet de ne pas lire ce fichier lors d’une commande qui doit être reproductible.

Sans @serveur, dig consulte normalement les serveurs de /etc/resolv.conf. Pour comparer une réponse, indiquez le serveur à interroger :

dig @192.0.2.53 example.com A

192.0.2.53 est une adresse fictive réservée aux exemples, à remplacer par l’adresse d’un serveur DNS autorisé de votre environnement. Cette commande ne configure pas le DNS du système : elle choisit le serveur pour cette interrogation. Si @serveur est un nom, sa résolution préalable intervient aussi.

Lire le statut avant les enregistrements

Dans une sortie complète, examinez le nom et le type de la question, status dans l’en-tête, les sections de données et le serveur indiqué par SERVER. La section ANSWER contient les réponses, qui peuvent inclure une chaîne de noms et plusieurs enregistrements.

NXDOMAIN et l’absence d’un enregistrement AAAA pour un nom qui possède un A sont deux situations différentes. Un résultat sans réponse peut aussi contenir des informations d’autorité ou de délégation : ne le résumez pas automatiquement à « domaine absent ».

Pour voir seulement les enregistrements de la réponse après avoir examiné son statut :

dig +noall +answer example.com A

Exemple fictif de format :

example.com. 300 IN A 192.0.2.10

Les champs donnent le nom, une durée TTL de 300 secondes, la classe Internet IN, le type A et la valeur IPv4. TTL signifie Time to Live et concerne la conservation en cache de l’enregistrement. La valeur observée chez un résolveur peut être le temps restant en cache ; ce n’est pas une promesse que tous les utilisateurs verront une modification dans exactement 300 secondes.

Utiliser les sorties courtes et les recherches inverses

dig +short example.com A
dig -x 192.0.2.10

+short réduit la sortie pour une lecture rapide, mais un affichage vide ne distingue pas à lui seul absence de données, NXDOMAIN, erreur de serveur et problème de communication. +noall +answer masque également l’en-tête : revenez à la commande complète pour lire le statut.

-x construit la recherche inverse de type PTR pour une adresse. L’adresse d’exemple ne possède pas ici de nom garanti. Une recherche inverse ne remplace pas la recherche A ou AAAA du nom, et l’absence de PTR ne prouve pas qu’aucun service n’existe à cette adresse.

Dans un script, le code de sortie de dig ne suffit pas à conclure que le nom existe : BIND dig peut retourner 0 dès qu’une réponse DNS est reçue, y compris NXDOMAIN. Examinez le statut et les données attendues, puis traitez séparément l’absence de réponse.

Comparer les caches et la résolution de l’application

1. Conservez le même nom complet et le même type pour comparer deux serveurs. Relevez SERVER, le statut, les valeurs et TTL ; un changement de type ne constitue pas une comparaison équivalente.
2. Distinguez le résolveur récursif, qui peut répondre depuis un cache, et le serveur faisant autorité pour une zone. Des vues internes et publiques peuvent volontairement fournir des réponses différentes.
3. Si dig répond mais que l’application échoue, contrôlez son propre chemin de résolution, ses caches et sa configuration réseau, puis le service lui-même.

dig interroge DNS directement pour le nom demandé. Une application peut passer par /etc/hosts, les services NSS, Name Service Switch, un résolveur local ou un mécanisme DNS propre. Un navigateur peut aussi employer un proxy ou un DNS différent. Pour comparer avec les bases de noms du système, la commande getent et les sources NSS répond à une autre partie du diagnostic.

+trace suit les délégations depuis la racine avec des requêtes itératives. Cette trace DNS ne montre pas les routeurs du réseau, contrairement à traceroute. Elle peut échouer si le réseau autorise seulement le résolveur interne. Avec +trace, @serveur ne choisit que le serveur de la requête initiale vers les informations de racine ; il ne force pas toutes les étapes à passer par ce serveur.

Le manuel officiel dig de BIND 9 explique les options d’affichage, les serveurs sélectionnés et les codes de retour. Vérifiez dig -v et man dig pour la version installée.