Vous avez besoin de vérifier un enregistrement DNS. Peut-être avez-vous changé d’hébergeur et souhaitez confirmer que votre domaine pointe vers le nouveau serveur. Peut-être vos e-mails rebondissent et vous suspectez un problème d’enregistrement MX. Ou un site affiche un mauvais contenu et vous essayez de déterminer s’il s’agit d’un problème DNS ou d’autre chose.

macOS dispose de trois commandes Terminal intégrées pour les recherches DNS : nslookup, dig et host. Toutes interrogent le DNS, mais chacune présente les résultats différemment et convient à des situations différentes.

Ce que fait réellement une recherche DNS

Lorsque vous tapez un nom de domaine dans votre navigateur, votre Mac demande à un résolveur DNS (généralement celui de votre FAI ou un public comme 1.1.1.1) de traduire ce nom en adresse IP. Le résolveur cherche la réponse et votre ordinateur se connecte à cette IP.

Une recherche DNS vous permet d’effectuer vous-même cette traduction et d’inspecter le résultat. Vous pouvez voir à quelle IP un domaine se résout, quels serveurs de messagerie gèrent ses e-mails, et quels serveurs de noms font autorité pour ce domaine. Cela couvre la plupart des besoins de débogage quotidiens.

Types d’enregistrements courants à connaître :

A : Adresse IPv4 (le principal que vous rechercherez)
AAAA : Adresse IPv6
MX : Serveur de messagerie, avec priorité
CNAME : Alias pointant vers un autre domaine
TXT : Enregistrements texte, utilisés pour SPF, DKIM, vérification de domaine
NS : Serveurs de noms faisant autorité pour le domaine

nslookup sur Mac : le point de départ familier

nslookup est la commande vers laquelle la plupart des gens se tournent en premier. Elle existe sur tous les systèmes d’exploitation, donc si vous avez déjà effectué des recherches DNS ailleurs, la syntaxe vous semblera familière.

Recherche d’enregistrement A de base

nslookup google.com

La sortie affiche le serveur DNS qui a répondu et l’adresse IP. La ligne « Non-authoritative answer » signifie simplement que le résultat provient d’un cache, pas des propres serveurs de noms du domaine. C’est normal.

Rechercher un type d’enregistrement spécifique

nslookup -type=MX google.com

Remplacez MX par n’importe quel type d’enregistrement : A, AAAA, CNAME, TXT, NS, SOA. Par exemple, pour vérifier SPF et DKIM pour le dépannage des e-mails :

nslookup -type=TXT google.com

Interroger un serveur DNS spécifique

C’est là que nslookup devient genuinement utile. Au lieu d’interroger votre résolveur par défaut (qui peut avoir mis en cache d’anciennes données), vous pouvez interroger directement un serveur spécifique :

nslookup google.com 8.8.8.8

nslookup google.com 1.1.1.1

Interroger plusieurs serveurs vous permet de voir si les changements DNS ont propagé. Si 8.8.8.8 affiche votre nouvelle IP mais que 1.1.1.1 affiche toujours l’ancienne, la propagation est encore en cours.

Mode interactif de nslookup

Tapez nslookup sans arguments et vous obtenez une invite. De là, vous pouvez effectuer plusieurs requêtes sans retaper la commande :

> set type=MX
> google.com
> set type=A
> example.com
> exit

Le principal inconvénient de nslookup est que sa sortie mélange les messages informatifs avec les résultats réels. Le formatage est incohérent selon les types d’enregistrements, ce qui rend la lecture plus difficile.

dig : l’outil puissant pour le DNS sur Mac

dig (Domain Information Groper) est l’outil préféré des administrateurs système et des développeurs qui font régulièrement du dépannage DNS. La sortie est structurée et cohérente, et les options de contrôle vont bien au-delà de nslookup.

Recherche de base

dig google.com

La sortie est verbeuse par défaut : la question posée, la section de réponse, le timing et le serveur qui a répondu. Ces informations supplémentaires sont utiles lors du débogage, car vous pouvez voir exactement ce qui a été retourné et combien de temps cela a pris.

Obtenir uniquement la réponse avec +short

Quand vous voulez une réponse rapide sans les détails environnants :

dig google.com +short

Cela ne retourne que l’adresse IP. Idéal pour les scripts ou quand vous voulez juste connaître le résultat :

dig google.com MX +short

Retourne les enregistrements MX avec les priorités, un par ligne.

Interroger des types d’enregistrements spécifiques

dig google.com MX
dig google.com TXT
dig google.com NS
dig google.com AAAA

Interroger un serveur DNS spécifique

dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @9.9.9.9 yourdomain.com

La syntaxe @ spécifie le résolveur. C’est la façon la plus propre de vérifier la propagation DNS sur plusieurs résolveurs publics.

Tracer le chemin de résolution complet

dig google.com +trace

Cela suit toute la chaîne de résolution DNS : serveurs racines, serveurs TLD, puis les serveurs de noms faisant autorité pour le domaine. Si le DNS est cassé quelque part dans la chaîne, +trace vous montrera exactement où il échoue.

Vérifier la validation DNSSEC

dig google.com +dnssec

Ajoute les enregistrements de signature DNSSEC à la sortie. Utile si vous vérifiez que la configuration DNSSEC d’un domaine est correcte après l’avoir activée.

host : l’option de lecture rapide

host fournit une sortie propre et lisible par l’homme avec une configuration minimale. C’est le bon choix quand vous voulez une réponse rapide et n’avez pas besoin du détail complet que fournit dig.

host google.com

Cela retourne les enregistrements A, AAAA et MX en une seule fois :

google.com has address 142.250.80.46
google.com has IPv6 address 2607:f8b0:4004:c1b::65
google.com mail is handled by 10 smtp.google.com.

Pour un type d’enregistrement spécifique :

host -t MX google.com
host -t TXT google.com

host manque des options avancées de dig, mais sa sortie est immédiatement lisible sans aucun paramètre.

Quel outil utiliser et quand

Commande	Idéal pour	Style de sortie
`nslookup`	Familiarité multiplateforme, vérifications rapides	Verbeux, messages mélangés
`dig`	Vérification de propagation, scripts, trace complète	Structuré, `+short` pour sortie propre
`host`	Réponse rapide lisible, aucun paramètre requis	Concis, texte brut
`dig +short`	Scripts, vérifications par lots, sortie minimale	Réponse brute uniquement
`dig +trace`	Trouver où la résolution DNS échoue	Chaîne complète depuis les serveurs racines
`NetUtil GUI`	Pas de Terminal, navigation visuelle des enregistrements	Pointer-cliquer, résultats formatés

Référence rapide : quel outil DNS utiliser selon vos besoins.

Cas d’utilisation concrets

Vérifier la propagation DNS après un changement d’hébergement

Vous avez déplacé votre site vers un nouveau serveur et mis à jour l’enregistrement A. Vous souhaitez maintenant savoir si le changement a propagé avant d’annuler l’ancien hébergement.

dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +short

Si les trois retournent la même IP, la propagation est terminée pour la plupart des utilisateurs. S’ils ne concordent pas, certains résolveurs servent encore les anciennes données en cache.

Pour voir combien de temps ce cache persistera, vérifiez le TTL :

dig @1.1.1.1 yourdomain.com

Dans la section de réponse, le nombre entre le nom d’enregistrement et le type d’enregistrement est le TTL en secondes. Un TTL de 300 signifie que le cache se vide dans 5 minutes. Un TTL de 86400 signifie que vous pourriez attendre 24 heures.

Déboguer la délivrabilité des e-mails avec les enregistrements MX

Les e-mails n’arrivent pas. Avant de fouiller dans les journaux SMTP, confirmez que les enregistrements MX sont corrects :

nslookup -type=MX yourdomain.com

Ou avec dig pour une sortie plus propre :

dig yourdomain.com MX +short

La sortie affiche vos noms d’hôtes de serveurs de messagerie et leurs priorités. Un nombre inférieur signifie une priorité plus élevée. Si les noms d’hôtes ne correspondent pas à ce que votre fournisseur d’e-mail vous a demandé de définir, voilà votre problème.

Vérifiez également les enregistrements TXT pour SPF et DKIM pendant que vous y êtes :

dig yourdomain.com TXT +short

Votre enregistrement SPF ressemblera à v=spf1 include:... ~all. S’il est absent ou mal formé, voilà pourquoi les messages vont dans le spam.

Déboguer pourquoi un site se charge sur la mauvaise IP

Votre domaine se résout vers une ancienne IP de serveur même si vous avez mis à jour l’enregistrement A il y a une heure.

Vérifiez d’abord ce que voit votre résolveur local :

dig yourdomain.com +short

Puis vérifiez ce que voit un résolveur externe :

dig @8.8.8.8 yourdomain.com +short

S’ils diffèrent, votre résolveur local a mis en cache l’ancienne réponse. Vous pouvez soit attendre que le TTL expire, soit vider votre cache DNS local :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Si les deux résolveurs affichent la même mauvaise IP, l’enregistrement A lui-même n’a pas été enregistré correctement. Reconnectez-vous à votre fournisseur DNS et vérifiez l’enregistrement.

Vérifier si un CNAME est correctement configuré

dig yourdomain.com CNAME +short

Cela retourne le domaine cible vers lequel pointe le CNAME. S’il ne retourne rien, vous n’avez pas de CNAME à ce nom (vous pourriez avoir un enregistrement A à la place, ce qui peut être intentionnel ou une mauvaise configuration).

Vider le cache DNS sur macOS

Lorsque vous avez besoin de vider le cache DNS de votre Mac après avoir modifié des enregistrements ou résolu un problème de résolution :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Cette commande fonctionne sur macOS Monterey, Ventura, Sonoma et Sequoia. Le processus mDNSResponder gère la résolution DNS locale, et lui envoyer HUP le force à se recharger.

Après avoir vidé le cache, exécutez à nouveau votre commande dig ou nslookup et vous devriez voir le résultat actualisé.

Si le Terminal n’est pas votre truc

Apple a supprimé Network Utility dans macOS Monterey, ce qui a supprimé la seule interface graphique intégrée pour les recherches DNS.

NetUtil est un remplacement gratuit. Ouvrez-le, tapez un domaine dans l’onglet Recherche DNS, sélectionnez un type d’enregistrement, et obtenez des résultats formatés de la même façon que l’ancien Network Utility. Pas de commandes à mémoriser, pas de paramètres à chercher. Les résultats sont les mêmes données que vous obtiendriez avec dig ou nslookup, juste présentées sans le bruit.

Pour les vérifications DNS occasionnelles, une interface graphique réduit la friction. Pour les recherches répétées ou tout ce que vous voudriez scripter, restez avec dig.

Choisissez le bon outil pour le travail

nslookup est bien pour les vérifications rapides, surtout si vous y êtes déjà habitué. dig est meilleur pour tout ce qui implique la vérification de propagation, les scripts ou l’exploration du comportement DNS. host est le chemin le plus rapide vers une réponse lisible par l’homme quand vous avez juste besoin de savoir à quelle IP un domaine se résout.

Les trois interrogent le même système DNS. Les différences sont dans la présentation et le contrôle. Utilisez celui qui vous donne l’information dont vous avez besoin sans vous ralentir.