Un DNS public qui fonctionne ne signifie pas qu’Active Directory est trouvable

Le VPN se connecte, le navigateur ouvre un site public, et l’ordinateur portable ne peut toujours pas ouvrir de session sur le domaine. La conclusion habituelle est que le DNS va bien parce que les noms se résolvent. Il ne va pas bien, et la raison est qu’un test dans le navigateur n’exerce qu’une seule requête d’une chaîne dont un client joint au domaine a besoin. La découverte du domaine demande d’abord les enregistrements de service, puis les adresses des contrôleurs que ces enregistrements nomment, puis une route vers les ports sur lesquels ces contrôleurs écoutent. Une réponse publique ne satisfait aucune de ces étapes.

Le mythe : les noms se résolvent, donc le DNS est réglé

Qu’un site public se résolve dit seulement qu’un résolveur a répondu à une requête A ou AAAA pour un nom d’une zone publique. Active Directory utilise le même protocole pour une autre question : où sont les services du domaine, et quel contrôleur ce client doit-il utiliser. La question s’exprime sous forme d’enregistrements SRV sous une zone nommée d’après le domaine, et un résolveur public récursif n’a aucune raison de les détenir.

Quand l’enregistrement manque, le résolveur renvoie une réponse négative, ce qui est une réponse DNS valide et non une panne. Le client se replie alors sur des informations de contrôleur en cache s’il en a, et c’est exactement pourquoi un poste de travail peut sembler aller bien pendant des heures et échouer après un redémarrage ou un changement de mot de passe.

Ce qu’un client de domaine demande réellement, dans l’ordre

Pour un domaine comme corp.example, la requête de localisation générique est _ldap._tcp.dc._msdcs.corp.example. Les réponses SRV nomment des contrôleurs candidats et leurs ports, puis le client a besoin d’enregistrements d’adresse pour ces noms d’hôte avant d’ouvrir une connexion. La découverte tenant compte du site ajoute des requêtes sous le sous-domaine du site, et les réponses déterminent quels contrôleurs sont préférés, et non lequel est obligatoire.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Suivez la chaîne dans cet ordre, depuis le réseau où le problème se produit. Un nom d’hôte qui se résout vers une adresse injoignable est une panne de routage, pas une panne DNS. Un contrôleur joignable dont les enregistrements de localisation manquent est une panne DNS, pas une panne de routage. Les deux produisent des plaintes d’utilisateurs similaires et des réparations complètement différentes.

Pourquoi un résolveur public répond et casse quand même l’ouverture de session

Si la carte réseau remet au client un résolveur public, les noms publics fonctionnent et l’espace de noms interne non. Ajouter un second résolveur public n’aide pas, car aucun des deux ne détient la zone. La liste courante « interne d’abord, public ensuite » ne se comporte pas non plus comme une règle par domaine : une réponse négative du premier serveur est une réponse légitime, et le client ne réessaie pas le second serveur simplement parce que la réponse était vide.

Les deux résolveurs internes, si vous en exploitez deux, doivent détenir l’espace de noms AD et être joignables depuis le réseau actuel du client. C’est précisément ce que cassent les conceptions en tunnel divisé : le VPN peut transporter le sous-réseau du tunnel tandis que le résolveur interne se trouve sur un préfixe que le tunnel ne route pas, si bien que la requête part vers un résolveur qui ne peut pas y répondre.

Windows applique aussi une stratégie de résolution de noms qui peut diriger des espaces de noms précis vers des serveurs précis, et les adresses DNS affichées par la carte réseau ne sont pas toute l’histoire. Changer la liste de la carte sans changer cette stratégie peut laisser la configuration effective intacte, et c’est pourquoi un correctif qui semble appliqué n’a aucun effet.

Gardez le DNS du tunnel et ses routes en accord

Un profil VPN qui pousse un résolveur mais pas le préfixe qui le contient crée un résolveur que le client ne peut pas joindre ; celui qui pousse le préfixe sans résolveur laisse le client interroger le local. Traitez la paire comme un seul élément de configuration et vérifiez les deux après chaque changement de profil, car une poussée réordonnée ou une nouvelle stratégie de tunnel divisé peut les séparer.

Vérifiez aussi ce que le client fait du réglage poussé. Certains clients n’appliquent le serveur DNS qu’à l’interface du tunnel et laissent le résolveur de la carte physique en place, si bien que le gagnant dépend de la métrique de l’interface et du nom interrogé. Si la réponse interne n’arrive que lorsque la carte physique est désactivée, c’est le mécanisme à corriger, pas les enregistrements du domaine.

Acceptez avec un appel de découverte et une opération en direct

Un test d’acceptation utile exécute la requête de localisation puis effectue une véritable opération authentifiée, comme ouvrir un partage adossé à l’annuaire ou demander un ticket. Faites-le avant la transition VPN et de nouveau après, sur la même machine, sans redémarrage entre-temps. Les identifiants en cache et les sessions déjà ouvertes feront volontiers passer un chemin cassé pour sain, donc une ouverture de session réussie sur le poste n’est pas le test.

Les recommandations de Microsoft pour le client DNS tracent la même frontière entre résoudre l’espace de noms interne et transmettre les requêtes publiques en amont, et c’est la disposition à préserver lors de l’introduction d’un VPN.

Si la défaillance n’est que lente et non échouée, gardez le délai séparé du diagnostic. Un dépassement de délai pendant la découverte peut venir d’un contrôleur injoignable, d’un port bloqué ou d’un résolveur qui répond tard, et rien de tout cela n’est prouvé par l’attente seule. Capturez la requête réelle, sa réponse et la tentative de connexion avant de modifier un réglage du résolveur.