nslookup indique un serveur inconnu : ce n’est qu’une étiquette

Connectez le VPN, lancez nslookup, et l’en-tête affiche l’adresse du résolveur avec le champ du nom rempli par Unknown. Ce mot se trouve au-dessus de la réponse, et la plupart des gens arrêtent de lire avant la partie qui compte. L’étiquette décrit si le résolveur possède son propre nom inverse ; elle ne dit encore rien sur le fait que le nom d’hôte demandé ait été résolu. Fermer cette fenêtre tôt est toute la compétence ici.

Deux requêtes différentes peuvent produire cet affichage, et une seule concerne votre problème. Les séparer coûte une commande supplémentaire et évite un après-midi à modifier des réglages DNS qui n’ont jamais été faux.

Ce que l’outil fait avant de vous répondre

nslookup peut chercher un nom pour l’adresse du serveur qu’il s’apprête à utiliser, ce qui est une recherche inverse dans le domaine in-addr.arpa ou ip6.arpa. Si cet enregistrement PTR manque, est filtré par une politique ou simplement n’est pas publié, l’outil affiche Unknown et continue. La résolution directe n’est pas touchée par cet échec, car c’est une autre question envoyée au même serveur.

C’est pourquoi un résolveur privé peut répondre correctement à chaque nom d’entreprise et paraître malgré tout anonyme dans l’en-tête de l’outil. L’adresse est connue ; le nom derrière ne l’est pas, et l’outil est honnête à ce sujet tout en restant un peu théâtral quant au mot qu’il choisit.

Lancez les deux requêtes délibérément

Demandez un hôte qui vous importe, puis demandez l’adresse du résolveur lui-même. La première requête porte le nom dont vous avez besoin ; la seconde demande au serveur s’il peut se nommer lui-même. Écrites, elles ressemblent à ceci : nslookup app.corp.example 10.77.0.53 pour l’hôte, et nslookup 10.77.0.53 10.77.0.53 pour le nom inverse du résolveur.

Les deux exemples sont illustratifs, remplacez-les donc par vos propres noms et adresses. Le point n’est pas la syntaxe exacte mais la séparation : les deux commandes posent des questions différentes et peuvent produire des résultats différents sans qu’aucune soit un dysfonctionnement.

Trois résultats qui se ressemblent et ne le sont pas

Un délai dépassé signifie qu’aucune réponse n’est arrivée du tout, ce qui indique un problème d’accessibilité, de filtrage ou une mauvaise adresse de serveur. Une réponse négative signifie que le serveur a répondu et dit que le nom n’existe pas, ce qui indique la zone ou le suffixe. Un nom inverse absent signifie que le serveur a répondu à la seconde question sans rien d’utile, et la réponse directe a peut-être été parfaite. Trois résultats, trois responsables, et un seul concerne le nom d’hôte dont vous aviez besoin.

Seuls les deux premiers décrivent un chemin DNS qui échoue pour votre application. Le troisième décrit un enregistrement qui n’a jamais été publié, et le traiter comme une panne mène à des changements qui ne peuvent pas le réparer, comme réécrire le suffixe de recherche jusqu’à ce que l’en-tête paraisse plus aimable.

Lisez les sections, pas l’en-tête

Sous l’en-tête, l’outil affiche la réponse, l’autorité et tout enregistrement supplémentaire. Une adresse correcte dans la section de réponse est le résultat que vous vouliez, même lorsque le nom de l’en-tête est Unknown. Une réponse vide avec un refus autoritaire est une autre issue et mérite sa propre enquête.

Gardez les deux objets explicites dans tout ce que vous envoyez au support : quel nom a été interrogé et quel serveur a été questionné. Les rapports qui mentionnent seulement que le DNS est cassé via le VPN forcent la personne suivante à reconstruire un test que vous avez déjà fait.

Quand un nom inverse compte vraiment

Certains services tiennent vraiment aux enregistrements PTR : la journalisation qui résout les adresses des clients, les contrôles de réputation des courriels ou les outils d’administration qui affichent des noms. Si l’un d’eux échoue, publiez l’enregistrement ou corrigez la zone qui devrait le contenir. Ce travail est légitime et distinct de la question de savoir si le VPN transmet correctement les requêtes.

Le point précis tient : une étiquette de résolveur manquante ne prouve pas que la résolution directe par le tunnel est cassée, et une recherche directe qui fonctionne ne prouve pas que chaque nom de la zone se résout. Testez le nom dont vous avez réellement besoin, puis décidez ce que vaut le mot de l’en-tête.