Quand un service ne répond plus par son nom de domaine, le problème ne vient pas forcément de l’application : le serveur DNS, un enregistrement ou la configuration réseau peuvent être en cause. Sous Debian, nslookup permet d’interroger rapidement un domaine, de comparer plusieurs résolveurs et de repérer où la résolution de noms bloque.
L’article en bref
Une commande simple peut déjà séparer une panne locale d’un problème de DNS externe. Voici comment utiliser nslookup sous Debian pour vérifier les réponses et orienter le dépannage.
- Première vérification : Interrogez un domaine et identifiez le serveur DNS utilisé.
- Résolveur ciblé : Comparez les réponses de plusieurs serveurs DNS configurés.
- Enregistrements utiles : Consultez les données A, MX, NS et SOA.
- Résultats à interpréter : Distinguez une réponse non autoritaire d’une véritable erreur.
À retenir : nslookup accélère le diagnostic réseau en rendant visible le chemin de résolution.
Installer nslookup sur Debian et lancer une première requête DNS
Sur Debian, nslookup est généralement fourni par le paquet bind9-dnsutils. S’il n’est pas déjà présent, installez-le avec les droits administrateur :
sudo apt update && sudo apt install bind9-dnsutils
Une fois l’outil disponible, une requête simple affiche le serveur DNS interrogé, puis les informations retournées pour le nom demandé :
nslookup exemple.net
La réponse contient habituellement l’adresse du résolveur dans les champs « Server » et « Address », puis l’adresse IP associée au domaine. Si le nom ne se résout pas, ces premières lignes aident déjà à distinguer un problème de serveur DNS d’un enregistrement absent ou incorrect.
Vérifier le serveur DNS configuré sous Debian
Sans serveur explicitement indiqué, nslookup utilise le résolveur défini dans la configuration réseau de la machine. Il peut s’agir d’une box, d’un serveur d’entreprise ou d’un service local ; la réponse affichée permet de voir quel serveur a effectivement été interrogé.
Par exemple, si un poste de studio ne parvient plus à joindre un serveur de fichiers par son nom, une réponse provenant d’un DNS inattendu donne une piste concrète : la configuration réseau peut avoir changé ou le résolveur local peut être indisponible. L’adresse IP du serveur DNS est donc aussi importante que celle du domaine recherché.
Interroger un autre serveur DNS pour comparer les réponses
Pour savoir si le problème vient du résolveur configuré ou de la zone DNS elle-même, lancez la même recherche auprès d’un second serveur. La syntaxe directe est :
nslookup exemple.net 1.1.1.1
Remplacez l’adresse par celle du DNS à tester, par exemple un résolveur public ou le serveur autorisé de votre réseau. Si le DNS habituel échoue mais que le second répond, le domaine existe probablement et la panne se situe plutôt du côté du résolveur initial ou de son accès aux données.
Pour effectuer plusieurs tests sans répéter la commande, ouvrez le mode interactif :
nslookup
À l’invite, saisissez server 1.1.1.1, puis les noms à contrôler. La commande exit permet de quitter. Cette méthode est pratique lors d’un dépannage où plusieurs hôtes d’un même service doivent être vérifiés.
Interpréter une réponse non autoritaire
Une réponse indiquée comme « non autoritaire » ne signifie pas que la requête a échoué. Elle indique généralement que le serveur interrogé a obtenu l’information depuis son cache ou un autre serveur, plutôt qu’en étant lui-même la source faisant autorité pour la zone.
À l’inverse, des erreurs comme NXDOMAIN signalent que le nom demandé est déclaré inexistant, tandis que SERVFAIL indique que le serveur n’a pas pu traiter la requête correctement. Une réponse REFUSED traduit un refus du serveur, souvent lié à ses règles d’accès. Le message doit être lu avec le serveur interrogé et le nom exact : c’est ce contexte qui transforme une sortie en diagnostic.
Consulter les enregistrements DNS avec nslookup
Un domaine ne se résume pas à une seule adresse IP. Selon le service en panne, il faut vérifier le type d’enregistrement pertinent : A pour une adresse IPv4, AAAA pour IPv6, MX pour les serveurs de messagerie, NS pour les serveurs faisant autorité ou SOA pour les paramètres principaux de la zone.
En ligne de commande, précisez le type avec l’option -type= ou -query=. Par exemple, cette requête recherche les serveurs de messagerie :
nslookup -type=mx exemple.net
Pour consulter le SOA, utile lorsqu’un changement DNS semble ne pas s’être propagé comme prévu :
nslookup -query=soa exemple.net
Les valeurs du SOA incluent notamment un numéro de série et des temporisations de zone. Elles aident l’administrateur à vérifier la version publiée et les mécanismes de mise à jour, mais ne remplacent pas l’examen de la configuration du serveur faisant autorité.
Choisir le bon type de requête DNS
| Type | Information recherchée | Exemple de commande |
|---|---|---|
| A | Adresse IPv4 associée à un nom d’hôte | nslookup -type=a exemple.net |
| AAAA | Adresse IPv6 associée à un nom d’hôte | nslookup -type=aaaa exemple.net |
| MX | Serveurs de messagerie et priorités | nslookup -type=mx exemple.net |
| NS | Serveurs de noms déclarés pour la zone | nslookup -type=ns exemple.net |
| SOA | Informations principales et numéro de série de la zone | nslookup -type=soa exemple.net |
| CNAME | Alias DNS associé à un autre nom | nslookup -type=cname www.exemple.net |
Les enregistrements TXT peuvent aussi être interrogés pour examiner des informations comme SPF, mais leur affichage dépend du contenu publié. Les recherches de type ANY sont souvent limitées par les serveurs et ne garantissent pas une liste complète : mieux vaut demander directement le type utile au diagnostic.
Effectuer une résolution inverse et suivre les erreurs DNS
La résolution inverse part d’une adresse IP pour chercher un nom associé, généralement au moyen d’un enregistrement PTR. Elle peut aider à contrôler l’identité déclarée d’un serveur, sans garantir que l’adresse et le nom se correspondent dans tous les environnements :
nslookup 192.0.2.25
Si aucun nom n’apparaît, cela ne prouve pas que l’hôte est inaccessible : l’enregistrement PTR peut simplement ne pas exister ou ne pas être publié. Pour séparer ces cas, vérifiez ensuite la connectivité et la résolution directe du nom attendu.
Quand le résultat est ambigu, activez le mode détaillé avec nslookup -debug exemple.net. Il fournit des éléments supplémentaires sur la requête et la réponse. Un échec immédiat peut aussi signaler un problème d’accès au résolveur, tandis qu’un délai important oriente vers la latence, un filtrage réseau ou un serveur surchargé.
Une méthode de dépannage réseau en quatre étapes
Dans une petite équipe, un service peut sembler hors ligne alors que seule sa résolution de noms est cassée. Pour éviter de modifier la configuration au hasard, procédez du test le plus simple vers le plus ciblé :
- Tester le nom concerné : lancez nslookup sur le domaine ou l’hôte exact utilisé par l’application.
- Identifier le résolveur : notez le serveur DNS affiché dans la réponse.
- Comparer les serveurs : refaites la requête auprès d’un résolveur de référence adapté au réseau.
- Vérifier l’enregistrement : interrogez son type précis et contrôlez la réponse attendue.
Si le premier serveur échoue et que le second répond, concentrez le dépannage sur le résolveur local, son cache, son accès réseau ou sa configuration. Si les deux renvoient la même absence, examinez plutôt le nom demandé et la zone DNS concernée.
Pour un diagnostic approfondi, dig fournit davantage de détails sur les échanges DNS, tandis que host privilégie une sortie courte pour les vérifications rapides. nslookup reste utile pour interroger un serveur et tester des enregistrements sans alourdir la procédure. Le bon outil est celui qui permet d’isoler la panne sans multiplier les changements.
Attention également au transport : le DNS utilise souvent UDP sur le port 53, mais certaines réponses nécessitent TCP, notamment lorsqu’elles sont volumineuses. Si un pare-feu bloque l’un de ces flux, la requête peut échouer ou être relancée en TCP ; modifier le port avec -port= ne fonctionne que si le serveur écoute réellement sur le port indiqué.
Questions fréquentes sur nslookup sous Debian
Comment installer nslookup sous Debian ?
Installez le paquet bind9-dnsutils avec sudo apt update puis sudo apt install bind9-dnsutils. La commande nslookup sera alors disponible dans le terminal.
Comment utiliser nslookup avec un serveur DNS précis ?
Indiquez le serveur à la fin de la commande, par exemple nslookup exemple.net 1.1.1.1. La réponse permet de comparer ce résolveur à celui configuré sur Debian.
Une réponse non autoritaire indique-t-elle une erreur ?
Non. Elle signifie généralement que le serveur fournit une réponse issue de son cache ou obtenue ailleurs, sans être l’autorité de la zone interrogée.
Pourquoi nslookup ne trouve-t-il pas un nom d’hôte ?
Vérifiez le nom saisi, le résolveur interrogé et le type d’enregistrement demandé. NXDOMAIN signifie que le nom est déclaré inexistant ; SERVFAIL ou REFUSED orientent vers un problème de traitement ou de politique du serveur.
Quelle différence entre nslookup et dig ?
nslookup convient aux vérifications rapides et au mode interactif. dig expose généralement davantage de détails sur la requête et la réponse, ce qui le rend utile pour un diagnostic DNS plus poussé.
