Antiseche dig et nslookup : interroger le DNS

Cette antisèche dig et nslookup met en avant les requêtes DNS que vous lancez vraiment : interroger les enregistrements A, AAAA, MX, TXT, NS et CNAME avec dig, réduire le résultat à une seule réponse avec dig +short, suivre la chaîne depuis la racine avec +trace, viser un résolveur précis avec @8.8.8.8, et faire une recherche inverse sur une IP avec dig -x. Nous les avons regroupées selon ce que vous vérifiez, pas par ordre alphabétique des options, pour que vous copiiez une ligne, changiez le domaine, et passiez à la suite. nslookup a sa propre section vers la fin, parce que sous Windows c'est souvent le seul installé, et la syntaxe diffère juste assez pour vous piéger.

Vous avez ouvert un terminal parce que quelque chose résout mal, ou ne résout pas du tout, et vous voulez la vérité directement depuis le DNS plutôt que ce que votre navigateur a mis en cache il y a une heure. C'est à ça que sert dig. Il pose une question précise à un serveur de noms et affiche exactement ce qui est revenu. Les recettes ci-dessous sont celles que nous utilisons au quotidien, les plus courantes d'abord, pour que vous copiiez une ligne, changiez votre domaine, et voyiez ce que disent vraiment les enregistrements.

Une chose à poser d'entrée. dig interroge le DNS et rien d'autre : il ne lit pas votre fichier hosts, il se moque de votre navigateur, il parle juste à un résolveur et rapporte la réponse telle quelle. C'est tout l'intérêt. Quand ping et dig ne sont pas d'accord, dig vous dit ce que la couche DNS contient réellement, et l'écart vient en général d'un cache local périmé.

Bases de dig : A, AAAA, MX, TXT, NS, CNAME

Le motif de base est dig DOMAINE TYPE. Nommez le type d'enregistrement voulu après le domaine. Omettez le type et dig prend A par défaut, l'adresse IPv4. Le reste, c'est juste choisir le bon type pour la question que vous posez.

La sortie complète de dig est un rapport, pas une seule ligne. Il renvoie votre question, puis la section ANSWER SECTION contient les enregistrements voulus, et en dessous viennent les sections autorité et additionnelle que vous pouvez ignorer la plupart du temps. La plupart du temps vous ne voulez pas le rapport, vous voulez la réponse, ce qui est la recette suivante.

Réduire le bruit : +short et +trace

Deux options changent ce que vous voyez. +short réduit le rapport aux seules valeurs de réponse. +trace fait l'inverse : il parcourt la délégation depuis les serveurs racine vers le bas, en montrant chaque saut, ce qui permet de trouver où la résolution casse vraiment.

+short est celui que vous taperez le plus. Comparez dig example.com (une douzaine de lignes) avec dig example.com +short (l'IP brute) et vous n'y reviendrez plus. Dégainez +trace quand un nom résout sur un réseau mais pas sur un autre : il vous montre exactement quel serveur de noms de la chaîne renvoie la mauvaise réponse ou tombe en timeout.

Viser un résolveur précis : @8.8.8.8

Par défaut dig utilise le résolveur de la config système (/etc/resolv.conf sous Linux). Mettez un @ devant une IP ou un nom d'hôte pour interroger ce serveur directement à la place. C'est l'astuce la plus utile pour les vérifications de propagation, parce que votre cache local et un résolveur public peuvent tenir des réponses différentes pour le même nom au même moment.

Quand vous changez un enregistrement chez votre registrar et voulez savoir s'il est passé en ligne, interrogez un résolveur public de cette façon plutôt que de faire confiance à votre propre machine. Si @8.8.8.8 montre déjà la nouvelle valeur et que votre recherche locale montre encore l'ancienne, l'enregistrement va bien et vous attendez juste l'expiration de votre cache. Notre outil de recherche DNS sur le site lance ce même genre de requête de résolveur depuis le navigateur quand vous n'êtes pas devant un terminal.

Recherche inverse : dig -x

Une recherche normale va du nom vers l'IP. Une recherche inverse va de l'IP vers le nom, en lisant l'enregistrement PTR. dig -x prend l'adresse et construit la requête in-addr.arpa peu commode pour vous, donc vous n'inversez jamais les octets à la main.

Les enregistrements inverses sont contrôlés par celui qui possède le bloc d'IP, pas par le propriétaire du domaine, donc beaucoup d'adresses n'ont aucun PTR. Une réponse vide est normale et n'est pas une erreur. Là où ça compte le plus, c'est la messagerie : les serveurs de réception vérifient souvent qu'une IP émettrice a des enregistrements direct et inverse cohérents, donc un PTR manquant ou discordant est une raison courante pour qu'un courrier légitime atterrisse en spam.

nslookup : le secours sous Windows

nslookup est livré sur chaque machine Windows et sur la plupart des installations Linux aussi. dig ne vient pas avec Windows par défaut. Donc quand vous êtes sur une machine Windows verrouillée sans rien d'installé, nslookup est l'outil que vous avez, et il convient parfaitement pour une vérification rapide. La syntaxe diffère de dig sur deux points : vous choisissez le type d'enregistrement avec -type= (ou -q=), et vous nommez le serveur après le domaine, pas avec un @.

nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup 8.8.8.8

Une bizarrerie à prévoir : nslookup étiquette les résultats tirés d'un cache comme Réponse ne faisant pas autorité, ce qui sonne inquiétant mais signifie juste que la réponse vient d'un résolveur récursif plutôt que du serveur autoritaire. C'est le cas normal et il n'y a pas à s'en faire. La sortie est aussi plus bavarde et plus difficile à scripter que dig +short, ce qui est la raison principale pour laquelle dig l'a emporté sous Linux et macOS.

Notre avis : apprenez dig, gardez nslookup pour la machine où rien d'autre n'est installé. Pour les vérifications quotidiennes dig +short et dig @résolveur domaine répondent à presque tout, et la sortie tombe directement dans un script sans gymnastique de parsing. nslookup gagne sa place pour une seule raison, il est déjà là sous Windows, donc quand vous ne pouvez rien installer il fait le travail. Si vous bougez entre les systèmes, installez les outils BIND sous Windows pour avoir dig partout, et traitez nslookup comme le secours plutôt que la valeur par défaut.

Et après

Voilà la trousse de travail. Choisissez le type d'enregistrement, réduisez avec +short, visez un résolveur avec @, inversez avec -x, et dégainez nslookup seulement quand dig n'est pas sur la machine. La plupart du débogage DNS réel est un mélange de ça, et le reste vous le recherchez comme tout le monde.

Si les enregistrements que vous lisez touchent à la messagerie, le même réflexe se transpose directement. Comprendre pourquoi des messages rebondissent ou tombent en spam commence en général par un dig TXT pour l'enregistrement SPF et un dig sur le sélecteur DKIM, puis une recherche inverse sur l'IP émettrice. Question différente, les mêmes trois ou quatre commandes, gardées à portée de main.

Questions fréquentes