Capture Split-DNS : dites où chaque observation a été faite

Deux personnes dépanent le même problème Split-DNS et obtiennent des adresses de résolveur différentes. L’une a utilisé un outil de recherche, l’autre a capturé des paquets sur l’adaptateur, et une troisième a lu les diagnostics du client lui-même. Aucune ne ment, et aucune ne décrit la même étape. Nommer le point d’observation transforme une contradiction en carte.

Une requête, plusieurs points d’observation

Pour un seul nom interne, il existe au moins cinq endroits à regarder : l’application et l’API de résolution qu’elle appelle, la stratégie de domaine effective sur le client, une capture sur l’adaptateur ou le filtre, une frontière de passerelle contrôlée et le résolveur qui reçoit réellement la requête.

Chacun répond à une question différente, et aucun à lui seul ne prouve où la requête est allée.

Une capture sur l’adaptateur montre des paquets, pas une intention. Elle ne dit pas quel résolveur le client a choisi, et une capture vide peut signifier une réponse en cache ou une autre API de résolution plutôt qu’un paquet abandonné. Traitez chaque observation comme une preuve sur une étape. Assemblez ensuite les étapes en un chemin.

Le filtre du client se situe entre l’application et le câble

Un client VPN avec Split-DNS applique la correspondance de domaine avant que le paquet quitte la machine. Les noms du suffixe tunnelisé vont au résolveur interne ; tout le reste va au résolveur local. Le filtre est une stratégie, et la stratégie peut varier selon la plateforme et la version du client.

Le guide Split-DNS de Secure Client de Cisco couvre la correspondance de domaine et le filtre Windows, et il sépare ce qu’une application voit lorsqu’elle utilise l’API de résolution native de ce que voit un outil comme nslookup. Ces distinctions sont le point.

Partez du profil effectif et d’une requête applicative ordinaire. Tout test qui nomme un serveur explicite est un détour délibéré ; expliquez-le avec les diagnostics du client lui-même et ne le laissez pas devenir le critère d’acceptation.

nslookup suit un chemin différent de celui de l’application

nslookup construit sa propre requête DNS et peut contourner la stratégie de résolution du système d’exploitation. Cela en fait un outil utile pour poser une question précise à un serveur précis, et un outil trompeur pour tester ce qu’une application vivra.

Sous Windows, la table de stratégie de résolution de noms décide quel suffixe utilise quel serveur. La lire montre la stratégie que l’application suivra, et c’est souvent la pièce manquante.

Lisez la stratégie, puis posez la même question via le résolveur normal :

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Les résolveurs chiffrés cachent la requête, pas la connexion

Un navigateur doté de son propre résolveur DNS-over-HTTPS est un cas tout autre. La requête sort à l’intérieur de TLS, si bien qu’une capture de paquets montre une connexion vers une adresse de résolveur mais pas le nom demandé.

Déterminez d’abord la stratégie gérée du navigateur, puis comparez-la à une requête du système d’exploitation. Un navigateur autorisé à choisir son propre résolveur peut ne jamais voir la stratégie Split-DNS.

La même prudence vaut pour tout client qui embarque son propre résolveur. Une capture qui identifie la connexion distante n’est pas une preuve sur le nom de la requête. Si vous avez besoin du nom, prenez-le dans les journaux du résolveur lui-même ou dans les diagnostics de l’application, avec les règles de confidentialité applicables.

Comparez avec un test étiqueté

Choisissez un nom interne approuvé pour le test, ainsi qu’un nom public qui ne porte aucun sens sensible. Pour chacun, consignez l’heure, le type d’enregistrement, la réponse et la stratégie attendue.

Là où c’est permis, comparez la réception du résolveur à une observation étroite du client ou de la passerelle :

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

N’envoyez jamais de noms privés à des résolveurs publics sans rapport uniquement pour créer une comparaison, et masquez tout ce que vous partagez. Enfin, séparez une réponse DNS correcte de la connexion au service qui suit : l’adresse privée résolue a encore besoin d’une route et d’une autorisation applicative.