Tester un DNS scindé sans fuiter de noms internes

Interroger un résolveur public sur un nom interne le divulgue et contourne la règle que vous vouliez tester. La requête atteint un serveur que vous ne contrôlez pas, la réponse vient d’un espace de noms qui n’aurait jamais dû le voir, et le résultat ne dit rien sur le fait que le DNS scindé fonctionne ou non. Tester un DNS scindé, c’est tester le chemin du résolveur qu’une application utilise réellement. Ce chemin est choisi par le système d’exploitation, par la liste de domaines du profil VPN et parfois par le navigateur.

Choisissez deux noms et prédisez d’abord les deux réponses

Demandez au responsable du réseau un nom de test interne documenté et choisissez un nom public ordinaire qui ne dit rien sur l’organisation. Écrivez ce qui devrait se produire pour chacun avant de lancer quoi que ce soit : le nom interne devrait atteindre le résolveur du tunnel et renvoyer une adresse interne, tandis que le nom public devrait être résolu via le résolveur que le système utilise habituellement. Ces deux prédictions sont le test, car sans elles, toute réponse peut être rationalisée après coup. Gardez le couple fixe d’une exécution à l’autre pour qu’une comparaison ultérieure ait un sens.

Vérifiez les règles effectives plutôt que les règles prévues. La liste de domaines attachée à la connexion VPN décide quels suffixes vont à quel résolveur, et une faute de frappe dans cette liste produit une scission plausible mais fausse. Sur un appareil géré, utilisez le chemin de diagnostic de l’administrateur, car les remplacements locaux peuvent être réinitialisés par une stratégie lors du prochain contrôle.

Notez la prédiction à côté de la réponse observée dans le même ticket. Un test sans prédiction ne peut pas échouer, et un test qui ne peut pas échouer n’apprend rien.

Testez le chemin qu’utilise l’application, pas un serveur que vous avez choisi

Une commande qui nomme explicitement un résolveur teste ce résolveur et rien d’autre. Elle indique si le serveur interne répond, ce qui est utile, et elle n’indique pas si une application envoie le nom là-bas. Testez d’abord par le chemin normal : résolvez le nom interne comme le ferait une application, puis résolvez le nom public de la même manière. C’est seulement ensuite que vous interrogez des serveurs précis pour trouver où le comportement diverge.

Les navigateurs compliquent le tableau, car les réglages de DNS sécurisé peuvent contourner entièrement le résolveur du système. Un navigateur configuré avec son propre résolveur chiffré ne voit jamais la scission, et la panne ressemble à un profil VPN cassé. Vérifiez ce réglage avant de changer le tunnel.

Répétez la recherche après une reconnexion si la question est la restauration. Une réponse mise en cache avant la reconnexion peut faire paraître une scission correctement restaurée meilleure ou pire qu’elle ne l’est.

Enregistrez la catégorie de réponse, pas seulement le succès ou l’échec

Notez laquelle de quatre choses s’est produite : une adresse interne, une adresse publique, une réponse négative ou un délai d’expiration. Chacune a un sens différent. Une adresse interne pour le nom interne est le succès attendu ; une adresse publique pour un nom interne suggère que la requête a quitté le tunnel ; une réponse négative du serveur faisant autorité indique un enregistrement manquant plutôt qu’une erreur de routage ; et un délai d’expiration indique un problème d’accessibilité ou un résolveur qui n’a jamais reçu la requête. Succès et échec sont trop grossiers pour agir.

Tenez compte du cache avant d’interpréter une requête fraîche absente, car une réponse négative en cache ressemble à un nom qui n’existe pas. Capturez la réponse avant d’effacer quoi que ce soit via des contrôles pris en charge, puisque la première réponse est la preuve.

Interprétez les deux branches sans deviner

Si le nom interne se résout correctement et que l’application échoue toujours, le résolveur a fait son travail et les suspects suivants sont les routes et les autorisations sur la ressource elle-même. Si le nom privé a atteint un résolveur public, la règle de scission ne s’applique pas à cette recherche ; examinez donc la liste de domaines et toute politique de navigateur avec le propriétaire de l’espace de noms. Ces deux branches ont des propriétaires différents, et c’est pourquoi noter laquelle vous avez vue importe plus que noter que quelque chose s’est cassé.

Masquez les données sensibles de la sortie partagée tout en gardant la structure : quel espace de noms, quelle règle, quelle catégorie de réponse. Une réponse de résolveur peut porter des adresses internes et des noms d’hôtes, et un ticket est un foyer durable pour les deux.

Remettez ensuite le résultat au propriétaire de l’espace de noms avec les deux catégories observées et les noms retirés. C’est une conversation de cinq minutes au lieu d’une semaine de spéculation.