Les noms internes courts échouent sur le VPN : le suffixe que vous ne voyez jamais
Un nom court ne fonctionne que parce qu’un suffixe de recherche le complète. Comparez le nom complet et le nom court pour distinguer un manque de suffixe d’une panne du résolveur.
Le nom court fonctionnait au bureau et échoue sur le VPN, alors que le nom complet se résout sans problème. Rien n’est cassé. Un nom nu comme intranet n’est pas un nom complet ; le client ajoute un suffixe issu de sa liste de recherche et interroge le résultat. Si le profil VPN ne fournit pas ce suffixe, la forme courte familière cesse d’exister.
C’est tout le mythe. Le DNS n’a pas cassé, la politique de recherche a changé.
Un nom nu n’est pas un nom
Quand vous tapez une seule étiquette, le résolveur doit décider quoi demander. Il essaie le nom tel quel, puis ajoute les entrées de la liste de recherche une par une jusqu’à ce que quelque chose réponde. Sous Linux, resolv.conf contrôle cet ordre avec les réglages search et ndots. Sous Windows, la liste de suffixes et la politique de résolution de noms font l’équivalent. Retirez le suffixe et le résolveur n’a plus rien à ajouter.
Un nom court qui fonctionne est donc la preuve d’une politique, pas la preuve d’un serveur DNS sain.
Ce que font la liste de suffixes et l’adresse du résolveur
Ces deux éléments sont constamment confondus. L’adresse du résolveur dit à qui demander ; la liste de suffixes dit sur quel nom interroger. Un VPN peut vous fournir un résolveur privé sans suffixe, ou un suffixe avec le mauvais résolveur. Une seule de ces pannes ressemble à une panne de DNS.
Vérifiez-les séparément, car réparer le mauvais consume une fenêtre de support.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Trois symptômes, trois responsables différents.
Testez d’abord le nom complet
Demandez le nom pleinement qualifié documenté par l’administrateur, pas une supposition. Un FQDN qui fonctionne prouve que le résolveur est joignable et que l’enregistrement existe, ce qui élimine la moitié des causes possibles en une seule requête. Utilisez un outil qui montre quel serveur a répondu, afin de ne pas lire un résultat en cache.
Gardez le test privé. Envoyer des variantes internes à un résolveur public divulgue des noms et teste une politique que personne n’avait prévue.
Où se situe la correction
Corrigez le profil propriétaire ou le système de gestion qui le génère. Une modification manuelle de la configuration locale du résolveur disparaît généralement à la reconnexion, ou s’applique à tous les réseaux que la machine rejoint, ce qui est pire.
Sous Windows, inspectez la politique effective plutôt que la case dont vous vous souvenez. Get-DnsClientNrptPolicy affiche les règles de résolution de noms réellement en vigueur.
Sous macOS, scutil --dns imprime la configuration du résolveur par interface délimitée, y compris les domaines de recherche poussés par le VPN.
Sous Linux, lisez la ligne search dans /etc/resolv.conf, mais vérifiez si un client VPN l’a réécrite. Si le fichier est géré, modifiez la source de vérité plutôt que le fichier généré. Une ligne search obsolète héritée d’un réseau précédent est une cause fréquente.
Que conserver avec le profil
Conservez le nom complet corrigé, la liste de suffixes et l’adresse du résolveur à côté du profil client. La prochaine personne qui signale que le site intranet est inaccessible pourra comparer trois valeurs connues au lieu de partir d’une page blanche.
Et si seule la forme courte échoue, dites-le dans le ticket. Cette phrase épargne un après-midi à l’équipe des résolveurs.