El DNS de la VPN funciona, pero los nombres .local siguen fallando: ¿quién los resuelve?

Dos equipos en la misma VPN, el mismo nombre de host, y solo uno de ellos lo resuelve: la diferencia normalmente no es el túnel sino qué resolutor respondió. En un escritorio Linux ese nombre puede viajar por el conmutador de servicios de nombres, por el stub de systemd-resolved o por un resolutor que la aplicación trajo consigo, y cada uno de ellos aplica su propia regla al mismo sufijo. El sufijo es donde las reglas divergen, porque .local no es una etiqueta neutra. Averigüe qué ruta toma realmente el programa que falla antes de cambiar el orden en que se ejecuta algo.

Dos resolutores, dos respuestas distintas

Una búsqueda tradicional de glibc recorre la línea hosts: de nsswitch.conf y pregunta a cada módulo por turnos hasta que uno responde. Un cliente que habla con systemd-resolved a través del stub listener pregunta en cambio a un solo proceso, y ese proceso aplica la política por enlace más sus propios casos especiales. Una aplicación que trae su propio resolutor, o que enlaza una biblioteca que lo hace, puede evitar ambos. Un nombre de host puede tener, por tanto, tres propietarios en un mismo equipo, y solo uno de ellos sabe qué pretendía la VPN.

Identifique al propietario antes de cambiar nada, porque la solución es distinta para cada uno de los tres. Un navegador y una herramienta de línea de órdenes en el mismo escritorio pueden discrepar legítimamente, y esa discrepancia es la pista, no el error. Si el navegador resuelve el nombre y la herramienta no, está depurando una ruta de resolutor y no una ruta de VPN. Confirme la ruta por separado, para que un fallo de enrutamiento no se confunda con un fallo del servicio de nombres. Cuando ambos coinciden, el fallo está por encima del host y la configuración del resolutor de aquí no merece otra edición.

Qué orden preguntó realmente a su resolutor

Dos órdenes de solo lectura responden preguntas relacionadas, y compararlas localiza el problema más rápido que leer la configuración. Use un nombre interno real y mantenga la salida privada, porque los registros internos siguen siendo internos. Ejecute ambas en la misma sesión en la que corre el programa que falla:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

La primera pregunta a través de los módulos configurados, que es lo que experimenta un programa típico. La segunda pregunta directamente a systemd-resolved e informa del enlace, el protocolo y el servidor que respondió. Consultar el servidor corporativo por dirección solo demuestra que el servidor tiene el registro, porque no dice nada sobre si la aplicación llegó a preguntarle. Lea el enlace que transporta la VPN y los dominios que declara, y después compare esa lista con el sufijo del nombre que falla.

Por qué .local se salta su zona unicast

la referencia de systemd-resolved afirma que los nombres de varias etiquetas que terminan en .local normalmente van a DNS multicast cuando mDNS está habilitado, en lugar de al DNS unicast ordinario. El RFC 6762 reserva ese espacio de nombres para multicast de enlace local, así que una zona corporativa puede tener un registro correcto al que nunca se consulta para ese sufijo. El túnel puede enrutar el resolutor a la perfección y aun así perder la carrera. Un ping que funciona desde la caché no dice nada sobre la consulta que acaba de ocurrir.

Hay una excepción documentada, y resuelve la mayoría de estos casos: cuando un enlace declara ese sufijo como dominio de búsqueda o dominio de enrutamiento, el demonio lo mantiene en la ruta unicast y se salta el caso especial de multicast. Eso es política por enlace y no una preferencia global. Dos equipos con el mismo servidor VPN pueden comportarse distinto cuando un perfil de red declara el dominio y el otro no, así que lea el perfil activo y no el que recuerda haber editado.

La excepción estrecha gana a una reordenación global

Para una zona existente que no puede renombrar, haga que los propietarios del resolutor y de la VPN declaren el dominio en la conexión que lo transporta. Una entrada de dominio de enrutamiento para ese único sufijo más la dirección de servidor prevista es un cambio pequeño con un propietario nombrado, y vive con el enlace en lugar de en un archivo editado a mano.

También sobrevive a una desconexión, porque la política del enlace se vuelve a aplicar cuando el enlace regresa. Editar el nsswitch.conf compartido es la alternativa tentadora y la más costosa, porque cambia el comportamiento de búsqueda de cada nombre del equipo, incluido el descubrimiento local. Desactivar el demonio multicast tampoco es equivalente: elimina el comportamiento local sin enseñar a ningún resolutor la zona corporativa. Si el servicio es nuevo y no heredado, póngalo bajo un subdominio que controle su organización y sáltese la competición por completo. Elija la excepción estrecha cuando el nombre esté fijado en el firmware o impreso en una etiqueta, y elija un subdominio nuevo cuando aún controle el cliente.

Qué demostrar después del cambio

Demuestre la solución con la propia búsqueda de la aplicación y no con una herramienta que instaló para probar, y vacíe cualquier caché que pudiera responder por ella. Después confirme la ruta del resolutor y el enlace que sirvió la respuesta. Por último compruebe que el descubrimiento local se comporta como antes del cambio, porque la impresora que deja de aparecer es la parte que la gente nota al final. Estas tres órdenes comprueban el nombre, la ruta y la identidad TLS en ese orden:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Una dirección correcta con el certificado equivocado sigue haciendo fallar a un cliente estricto, así que compruebe el nombre que espera la aplicación cuando la resolución funcione. Confirme que el servicio acepta conexiones desde la dirección de la VPN y no solo desde el rango de la oficina. Escriba el alcance del dominio, el servidor y el propietario en la documentación de la conexión. De lo contrario, la siguiente persona que se encuentre con este fallo recurrirá a la misma edición global que usted acaba de evitar.