Pourquoi votre entrée /etc/hosts n’atteint pas le DNS du VPN

Vous avez ajouté un nom dans /etc/hosts, vous vous êtes connecté au VPN et vous attendiez à ce que l’enregistrement apparaisse pour tout le monde. Ce n’est pas le cas, et la surprise s’accompagne généralement d’un second symptôme : le nom se résout sur votre machine et échoue chez un collègue, ce qui ressemble à un service DNS du VPN en panne et est en réalité le fichier hosts qui fait exactement ce pour quoi il a été conçu. Un fichier hosts est une configuration locale de résolution de noms, pas une mise à jour de zone, et rien dans une connexion VPN normale ne le téléverse.

Hosts est une substitution locale, pas une mise à jour de zone

Le fichier est une liste de correspondances que les bibliothèques de service de noms consultent avant, ou à la place, d’interroger un serveur DNS. Une ligne comme 10.40.0.20 build.corp.example change ce que les applications de cette seule machine en concluent. Elle ne crée pas d’enregistrement, elle ne traverse pas le tunnel, et le serveur DNS vers lequel le tunnel pointe n’a aucune idée qu’elle existe.

C’est pourquoi l’échec est asymétrique. Votre client obtient une réponse du fichier. Un autre client interroge le serveur DNS du VPN, qui ne renvoie rien, et l’application signale que le nom n’existe pas. Les deux machines se comportent correctement ; une seule possède une substitution que l’autre n’a jamais vue.

Deux commandes, deux composants différents

Le moyen le plus rapide de clore le débat est de rendre la différence visible dans deux commandes, toutes deux exécutées sur le client qui possède l’entrée hosts :

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

La première interroge le chemin de recherche propre au système, qui sur un système glibc typique lit les fichiers locaux avant le DNS. La seconde envoie une requête DNS directement au serveur à cette adresse et ne consulte pas du tout les fichiers locaux. Quand la première renvoie votre entrée et que la seconde renvoie NXDOMAIN, vous avez prouvé que l’enregistrement n’existe pas dans le DNS et que votre machine répond depuis une substitution locale.

L’ordre est configurable, et cela vaut la peine d’être vérifié avant de conclure quoi que ce soit sur une distribution particulière. Regardez la ligne hosts: dans /etc/nsswitch.conf ; hosts: files dns consulte les fichiers en premier. Ne copiez pas cet exemple sur une configuration qui fonctionne simplement pour changer l’ordre, car les systèmes réels listent souvent des sources supplémentaires et des entrées de service conditionnelles que l’exemple ne contient pas.

systemd-resolved brouille le test

Sur un système qui utilise systemd-resolved, le stub local sert aussi des noms issus de la base hosts. Interroger 127.0.0.53 n’est donc pas un test indépendant du serveur distant, même si cela ressemble à une requête DNS et s’y comporte comme telle. Vous pouvez confirmer ce que le résolveur sait et quels serveurs il interrogerait avec :

resolvectl query build.corp.example
resolvectl status

La sortie status nomme les serveurs DNS par lien, et c’est ainsi que vous découvrez si le lien VPN a réellement reçu un résolveur. Cette question est distincte de l’entrée hosts et c’est celle qu’il vaut la peine de poser quand un nom privé échoue pour tous les utilisateurs et pas pour un seul.

Les applications peuvent ajouter une autre couche. Un navigateur avec son propre réglage DNS-over-HTTPS, un conteneur avec sa propre configuration de résolveur, ou un environnement d’exécution qui met en cache les recherches pendant toute la durée de vie du processus peuvent chacun répondre différemment du système. Testez l’application qui vous intéresse au lieu de supposer qu’une commande décrit tous les programmes de la machine.

Ce qui partage réellement un nom à travers le VPN

Si un nom privé doit fonctionner pour tout le monde, il lui faut un propriétaire que le résolveur de chacun peut atteindre. La réponse propre est de publier l’enregistrement dans une zone gérée et de rendre cette zone résoluble par le chemin DNS prévu du VPN. L’enregistrement a alors une source de vérité unique, une piste d’audit et un cycle de vie, et personne n’a à se rappeler quel portable porte une substitution locale.

Distribuer des fichiers hosts est une alternative légitime, et c’est de la gestion de postes de travail plutôt qu’un service de noms. Si vous la choisissez, le fichier doit être déployé, versionné et retiré par ce qui gère le parc, et cela doit être décrit ainsi dans la conception. « Le VPN s’en charge » n’est pas une description de ce processus.

L’enregistrement DNS dynamique est un troisième mécanisme, avec ses propres autorisations, son authentification des mises à jour et sa durée de vie d’enregistrement. Il ne découle pas d’une entrée hosts, et il ne découle pas non plus d’un client qui se connecte simplement, sauf si le serveur et le client ont tous deux été configurés pour cela. Un enregistrement qui apparaît tout seul est le signe que quelqu’un a activé les mises à jour sécurisées et un client qui s’enregistre lui-même, et cette configuration appartient au dossier de conception plutôt qu’à un fil de dépannage. Si personne ne peut nommer le propriétaire de ce réglage, traitez l’enregistrement automatique comme non vérifié et gardez la zone gérée comme source de vérité.

Un nom résolu n’est pas une route

La résolution de noms et l’accessibilité sont distinctes, et une correspondance locale obsolète est la façon classique de les confondre. Une entrée hosts qui pointe vers une adresse qui a déménagé continuera de sélectionner l’hôte obsolète longtemps après que le DNS a été corrigé, et le symptôme ressemble à une panne de routage sur un nom qui se résout bien.

Ainsi, lorsque le rapport indique « le nom se résout mais le service est inaccessible », comparez la recherche système avec une requête explicite au serveur DNS du VPN, puis vérifiez l’adresse obtenue par rapport à celle que le service utilise réellement. La référence systemd-resolved documente les sources locales qu’il consulte, et c’est la carte dont vous avez besoin pour cette comparaison.

Corrigez ensuite la substitution via son propriétaire. Retirer une ligne de votre propre fichier hosts ne fait rien pour les douze portables qui ont reçu la même ligne d’un script de déploiement, et c’est la version de ce problème que les gens ont réellement.