Por qué tu entrada en /etc/hosts no llega al DNS de la VPN

Añadiste un nombre a /etc/hosts, conectaste la VPN y esperabas que el registro apareciera para todos. No ocurre, y la sorpresa suele venir con un segundo síntoma: el nombre se resuelve en tu máquina y falla en la de un compañero, lo que parece un servicio DNS de la VPN roto y en realidad es el archivo hosts haciendo exactamente aquello para lo que fue diseñado. Un archivo hosts es configuración local de resolución de nombres, no una actualización de zona, y nada en una conexión VPN normal lo sube.

Hosts es una sustitución local, no una actualización de zona

El archivo es una lista de asignaciones que las bibliotecas de servicio de nombres consultan antes de, o en lugar de, preguntar a un servidor DNS. Una línea como 10.40.0.20 build.corp.example cambia lo que concluyen las aplicaciones de esa única máquina. No crea un registro, no viaja por el túnel, y el servidor DNS al que apunta el túnel no tiene ni idea de que existe.

Por eso el fallo es asimétrico. Tu cliente obtiene una respuesta del archivo. Otro cliente pregunta al servidor DNS de la VPN, que no devuelve nada, y la aplicación informa de que el nombre no existe. Ambas máquinas se comportan correctamente; solo una tiene una sustitución que la otra nunca ha visto.

Dos comandos, dos componentes distintos

La forma más rápida de zanjar la discusión es hacer visible la diferencia en dos comandos, ambos ejecutados en el cliente que tiene la entrada de hosts:

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

El primero pregunta a la propia ruta de búsqueda del sistema, que en un sistema glibc típico lee archivos locales antes que el DNS. El segundo envía una consulta DNS directamente al servidor de esa dirección y no consulta archivos locales en absoluto. Cuando el primero devuelve tu entrada y el segundo devuelve NXDOMAIN, has demostrado que el registro no existe en el DNS y que tu máquina responde desde una sustitución local.

El orden es configurable, y merece la pena comprobarlo antes de concluir nada sobre una distribución concreta. Mira la línea hosts: en /etc/nsswitch.conf; hosts: files dns consulta primero los archivos. No copies ese ejemplo sobre una configuración que funciona solo para cambiar el orden, porque los sistemas reales suelen enumerar fuentes adicionales y entradas de servicio condicionales que el ejemplo no incluye.

systemd-resolved enturbia la prueba

En un sistema que usa systemd-resolved, el stub local también sirve nombres de la base de datos hosts. Por eso consultar 127.0.0.53 no es una prueba independiente del servidor remoto, aunque parezca una consulta DNS y se comporte como tal. Puedes confirmar qué sabe el resolutor y a qué servidores preguntaría con:

resolvectl query build.corp.example
resolvectl status

La salida de status nombra los servidores DNS por enlace, y así es como averiguas si el enlace de la VPN recibió algún resolutor. Esa pregunta está separada de la entrada de hosts y es la que merece la pena hacerse cuando un nombre privado falla para todos los usuarios y no para uno.

Las aplicaciones pueden añadir otra capa. Un navegador con su propia configuración de DNS-over-HTTPS, un contenedor con su propia configuración de resolutor o un entorno de ejecución que almacena consultas durante toda la vida del proceso pueden responder cada uno de forma distinta al sistema. Prueba la aplicación que te importa en lugar de suponer que un comando describe todos los programas de la máquina.

Qué comparte realmente un nombre a través de la VPN

Si un nombre privado tiene que funcionar para todos, necesita un propietario al que el resolutor de todos pueda llegar. La respuesta limpia es publicar el registro en una zona gestionada y hacer que esa zona sea resoluble por la ruta DNS prevista de la VPN. Entonces el registro tiene una sola fuente de verdad, un rastro de auditoría y un ciclo de vida, y nadie tiene que recordar qué portátil lleva una sustitución local.

Distribuir archivos hosts es una alternativa legítima, y es gestión de equipos finales más que servicio de nombres. Si la eliges, el archivo tiene que ser desplegado, versionado y retirado por lo que gestione el parque, y así debe describirse en el diseño. «La VPN se encarga de eso» no es una descripción de ese proceso.

El registro dinámico de DNS es un tercer mecanismo, con sus propios permisos, autenticación de actualizaciones y vida útil del registro. No se deriva de una entrada de hosts, y tampoco se deriva de un cliente que simplemente se conecta, a menos que el servidor y el cliente estén ambos configurados para hacerlo. Un registro que aparece solo es una señal de que alguien habilitó las actualizaciones seguras y un cliente que se registra a sí mismo, y esa configuración pertenece al registro de diseño y no a un hilo de resolución de problemas. Si nadie puede decir quién es el propietario de ese ajuste, trata el registro automático como no verificado y mantén la zona gestionada como fuente de verdad.

Un nombre resuelto no es una ruta

La resolución de nombres y la alcanzabilidad son cosas separadas, y una asignación local obsoleta es la forma clásica de confundirlas. Una entrada de hosts que apunta a una dirección que se ha movido seguirá seleccionando el host obsoleto mucho después de que se haya corregido el DNS, y el síntoma parece un fallo de enrutamiento en un nombre que se resuelve bien.

Así que cuando el informe es «el nombre se resuelve pero el servicio no es alcanzable», compara la consulta del sistema con una consulta explícita al servidor DNS de la VPN y luego comprueba la dirección que obtuviste con la que el servicio usa realmente. La referencia de systemd-resolved documenta las fuentes locales que consulta, y ese es el mapa que necesitas para esa comparación.

Después corrige la sustitución a través de su propietario. Quitar una línea de tu propio archivo hosts no hace nada por los doce portátiles que recibieron la misma línea de un script de despliegue, y esa es la versión de este problema que la gente tiene de verdad.