Deux serveurs DNS sur une carte ne séparent pas les espaces de noms

Lister deux résolveurs sur une carte réseau ressemble à un moyen d’envoyer un domaine vers un serveur et un autre domaine vers l’autre, et rien dans la liste des résolveurs ne fonctionne ainsi. Windows résout par nom, et la décision du serveur à interroger vient d’objets de stratégie plutôt que d’une liste ordonnée d’adresses. Le modèle mental à remplacer est la file d’attente : il n’y a pas de premier serveur pour le domaine A ni de second serveur pour le domaine B. Il existe un jeu de règles par espace de noms qui nomme les serveurs explicitement, et une fois ces règles présentes, la liste de la carte cesse d’être intéressante.

Le mythe : deux adresses séparent deux domaines

La croyance survit parce qu’elle fonctionne par accident quand un serveur répond à tout et que le second n’est qu’un secours. Un client interroge le premier serveur, celui-ci transfère ou récure, et la réponse arrive ; personne ne remarque quel résolveur détenait réellement la zone. L’illusion se brise au moment où les deux espaces de noms vivent dans des zones privées séparées sans transfert entre elles, car le premier serveur répond alors avec autorité que le nom n’existe pas. Une réponse négative du premier serveur ne déclenche pas le secours, puisque le client a reçu une réponse définitive et non un échec.

Une liste ordonnée n’a aucun concept de domaine, elle ne peut donc pas exprimer l’intention. Ce que la liste contrôle réellement, c’est quel serveur est interrogé en premier et lequel est essayé en second, et ces deux réponses s’appliquent également à chaque nom.

Ce que Windows utilise réellement pour choisir

La table de stratégie de résolution de noms associe un nom à des espaces de noms configurés et sélectionne les serveurs et les options correspondants. Les règles peuvent être configurées localement, fournies par stratégie de groupe ou par un profil VPN, et la stratégie effective est une combinaison plutôt qu’une liste unique. C’est pourquoi le premier diagnostic est toujours l’état effectif : une règle créée localement qui perd face à une stratégie gérée produit un laboratoire qui ne se comporte pas du tout comme sa configuration le suggère. Les règles sont aussi comparées par spécificité, si bien qu’une entrée d’espace de noms large peut masquer une entrée étroite d’une manière invisible dans une liste d’éléments configurés. Lire l’ordre effectif est le seul moyen de voir quelle règle gagne.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

La première commande liste ce qui est configuré sur la machine ; la seconde montre ce que le client appliquera réellement, y compris les entrées venues d’ailleurs. Si la sortie effective contient des espaces de noms gérés, le propriétaire de cette stratégie est le bon endroit pour demander le changement, et non la liste locale de règles. Les deux commandes ne font que lire l’état, donc les exécuter avant que quiconque accepte le changement ne coûte rien.

Une règle par espace de noms, conservez l’objet

Une fois l’état effectif compris, créez une règle par espace de noms et conservez l’objet que chaque commande renvoie. Les noms d’affichage sont des étiquettes pour les humains, et l’identifiant unique de l’objet renvoyé est ensuite la cible de suppression fiable. Inscrivez les deux identifiants dans la même note de changement qui consigne les espaces de noms et les résolveurs, car la session qui les a créés ne sera pas celle qui nettoie.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Le point initial signale une correspondance de suffixe, la règle couvre donc app.svc.internal.example et tout ce qui se trouve en dessous. Les deux adresses ici appartiennent au plan de routage propre à ce laboratoire ; une règle ne crée pas de zone, n’installe pas de route et n’autorise pas l’application qui finit par se connecter, et la référence Add-DnsClientNrptRule documente exactement quel paramètre fait quoi.

Notez ce que ces commandes ne font pas : elles sont à l’échelle de la machine, elles ne sont pas limitées à une session VPN, et elles survivent à la fermeture de la fenêtre. Un laboratoire qui l’oublie laisse des stratégies derrière lui une fois le tunnel disparu.

Prouvez que le client a choisi le serveur

Demander à un serveur précis s’il connaît un nom prouve que ce serveur peut répondre, ce qui n’est pas la même affirmation que le fait que le client ait choisi ce serveur. Le test qui compte résout un nom réel par le chemin ordinaire du client puis confirme quel résolveur l’a traité, idéalement pendant que le tunnel qui fournit la route est actif. Si le tunnel est coupé, une règle correctement délimitée pointe encore vers un serveur injoignable, ce qui est un problème de routage et non de stratégie. Testez les deux états pour pouvoir les distinguer plus tard.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Surveillez les réponses mises en cache de la période antérieure aux règles, et surveillez les applications qui contournent entièrement le résolveur du système avec leur propre DNS chiffré. Les suffixes de recherche sont une autre fonction distincte : une règle peut choisir un résolveur pour un nom complet sans apprendre à Windows à développer un nom d’hôte nu dans cet espace de noms.

Supprimez exactement ce que vous avez créé

Le nettoyage est l’endroit où un laboratoire devient une histoire édifiante. Supprimer toutes les règles de la machine est rapide et retire des stratégies dont quelqu’un d’autre dépend, alors utilisez les identifiants capturés lors de la création des règles, et relisez l’état effectif ensuite pour confirmer que la machine est revenue là où elle avait commencé. Si la session qui les a créés a disparu, la note de changement est le seul endroit où les identifiants existent. C’est la raison de les écrire avant l’exécution de la première commande, et non après.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Pour un déploiement plutôt qu’un laboratoire, la question de la durée de vie compte autant que la règle. Un profil VPN peut porter les règles d’espace de noms et choisir si elles persistent au-delà de la connexion ; une règle qui persiste alors que le résolveur est injoignable laisse les clients préférer un serveur mort, et une règle limitée à la connexion disparaît avec le tunnel. Décidez laquelle de ces comportements le service exige, indiquez qui possède la règle, et laissez la répartition de l’autorité documentée à côté du profil plutôt que dans la mémoire de quelqu’un sur un laboratoire.