Fichier de résolveur macOS pour un domaine local à côté d’un VPN

Votre VPN professionnel résout parfaitement les noms de l’entreprise tandis que l’imprimante à la maison reste injoignable par son nom, et la solution habituelle vers laquelle les gens se tournent est de pointer tout le Mac vers le routeur domestique. C’est un changement bien plus important que ce que le problème exige. macOS peut envoyer un seul suffixe DNS vers son propre serveur au moyen d’un petit fichier de résolveur, en laissant toute autre requête exactement là où elle était.

La limite d’autorisation vient d’abord : ceci concerne un domaine que vous administrez ou pour lequel vous êtes autorisé à configurer. Ce n’est pas une route contournant la politique DNS imposée par une organisation ni ses restrictions de réseau local.

Un fichier au rôle étroit

Supposons que la zone locale soit lab.example.org et que son serveur réponde à 192.168.55.1. Sur un Mac où vous êtes autorisé à faire la modification, un administrateur crée un fichier texte simple dont le nom est le domaine lui-même, /etc/resolver/lab.example.org, contenant une seule nameserver 192.168.55.1 ligne. Le répertoire peut ne pas exister sur un système neuf, créez-le donc avec les droits d’administrateur, et regardez avant d’écrire au cas où un logiciel de gestion posséderait déjà un fichier à cet endroit.

La configuration de résolveur d’Apple documente la convention selon laquelle le nom du fichier fournit le domaine lorsque aucun réglage de domaine distinct n’apparaît dans le fichier. Cette règle de nommage est toute l’astuce, et c’est pourquoi le fichier doit être nommé d’après la zone et non d’après le serveur.

Comment macOS choisit entre les résolveurs

Plus d’un client de résolveur peut être actif, et le domaine correspondant le plus spécifique l’emporte. Un résolveur pour lab.example.org a donc une portée différente du résolveur par défaut, et un sous-domaine plus spécifique avec son propre fichier peut à nouveau prendre la priorité. C’est ce qui permet à un VPN professionnel de conserver son propre suffixe tandis que votre zone de laboratoire va ailleurs. Rien dans cet agencement n’est global, et c’est le point qui mérite d’être retenu.

Laissez /etc/resolv.conf tranquille. macOS écrit ce fichier lui-même, et il n’a jamais contenu l’image complète de la résolution propre à un domaine. La configuration peut aussi venir de la base de données de configuration du système plutôt que de fichiers de ce répertoire, et c’est pourquoi un profil de gestion peut écraser ce que vous avez écrit.

Trois choses que le fichier ne peut pas fournir

Le serveur doit être joignable. Si le VPN bloque la mise en réseau locale, ou si une route d’entreprise capture la plage d’adresses du serveur, un fichier de suffixe parfaitement correct ne peut toujours pas livrer une requête. Portez cela au propriétaire du réseau plutôt que d’élargir vous-même des exceptions locales.

La zone doit contenir la bonne réponse, et cela se teste mieux avec un nom pleinement qualifié comme printer.lab.example.org. Un nom court peut déclencher le comportement de domaine de recherche et finir par poser une question différente de celle que vous vouliez poser.

Enfin, l’application doit pouvoir utiliser la réponse. Résoudre le nom d’une imprimante ne donne pas accès à son adresse, et n’ouvre pas le service derrière elle. L’adresse renvoyée a encore besoin d’une route autorisée et d’une politique d’accès qui permette la connexion. Un fichier de résolveur change l’endroit où un nom est recherché ; il ne réserve pas de chemin pour le résultat.

Vérifiez la sélection au lieu de remplacer le DNS

Vérifiez ce que macOS utilise réellement en ce moment, et interrogez le nom pleinement qualifié depuis l’application elle-même ou depuis un outil qui résout comme le font les applications. Une requête directe à 192.168.55.1 prouve que le serveur répond ; elle ne prouve pas que macOS a choisi ce serveur pour les recherches ordinaires. Ce sont des faits différents, et seul le second décrit ce que votre navigateur vivra.

Si un autre résolveur revendique déjà le même suffixe, découvrez à qui il appartient avant d’ajouter des indications de priorité. Le réglage search_order documenté ordonne les clients qui partagent un domaine ; ce n’est pas un interrupteur global de préférence qui ferait gagner un résolveur général à chaque requête.

Confirmez que les noms de l’entreprise se résolvent toujours avec le VPN connecté, puis consignez le fichier et son objectif dans vos notes locales. Quand l’agencement est retiré, supprimez uniquement ce fichier et revérifiez les deux espaces de noms au lieu de réinitialiser tous les réglages DNS du réseau.