El DNS de la VPN se lleva cada consulta: corrige dns-priority en NetworkManager

Conecta la VPN de la oficina y de pronto cada consulta de nombre va al resolutor corporativo. Los nombres públicos siguen resolviéndose, así que nada parece roto hasta que falla el nombre de una impresora local o un registro split-horizon devuelve la dirección de la oficina. En algunas instalaciones de Fedora ocurre lo contrario: el resolutor del proveedor sigue respondiendo cuando el túnel ya está levantado. Ambas cosas son una sola pregunta — qué resolutor es dueño de esta consulta — y en los sistemas NetworkManager la respuesta vive en las propiedades DNS de cada conexión.

Dos conexiones, un resolutor ganador

Cada conexión declara una prioridad DNS. Las conexiones normales tienen 50 por defecto y las de VPN 0, y gana el valor más bajo. Ese valor por defecto es la razón de que una conexión VPN supere en silencio al enlace por cable para cada dominio que reclama: cero gana a cincuenta sin que nadie lo haya elegido.

La prioridad ordena a los candidatos. No limita sobre qué se pregunta al ganador. Una conexión VPN sin dominio de búsqueda reclama todo, así que preferirla también envía las consultas públicas dentro del túnel y, en un diseño de túnel dividido, adonde el resolutor corporativo reenvíe.

La prioridad decide el orden, la lista de búsqueda decide la propiedad

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

La lista de búsqueda es la declaración de propiedad. Un dominio desnudo como corp.example se convierte en sufijo de búsqueda y en dominio de enrutamiento. La forma solo de enrutamiento ~corp.example envía las consultas bajo ese sufijo a esta conexión sin añadir el dominio a los nombres cortos. Esa tilde es la diferencia entre «pregunta a este servidor» y «pregunta a este servidor y termina mi escritura».

Usa ambas formas cuando los usuarios escriben nombres de host cortos y los registros también se dirigen con nombres totalmente cualificados. Usa solo la forma de enrutamiento cuando quieras la división sin cambiar cómo completa el resolutor un nombre desnudo.

Luego haz explícita la preferencia y reactiva:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Una prioridad negativa es la forma documentada de decir «prefiere esta conexión», y fijar las dos familias de direcciones mantiene el comportamiento coherente en un equipo con conectividad IPv6. Cambiar la propiedad sin reactivar la conexión no cambia nada de lo que está corriendo ahora, por eso la secuencia termina con un up explícito.

Deja que systemd-resolved sostenga la división

El complemento dnsmasq por defecto embuda las consultas en un solo resolutor local, así que la separación por enlace queda gruesa. systemd-resolved expone la división por enlace, y resolvectl query nombra el enlace que respondió.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Después de eso, el enlace corporativo lleva corp.example y un resolutor público sirve el resto. Cuando una consulta llega al enlace equivocado, el comando nombra el enlace que la respondió, y saberlo vale más que saber solo la dirección.

Ajusta el diseño de DNS al tipo de túnel

Los diseños de privacidad que lo envían todo por el túnel no deberían llevar una lista de división, porque devolvería los nombres públicos al resolutor local y desharía la intención. Los diseños de túnel dividido necesitan una: sin ella el resolutor corporativo ve cada consulta pública, y la configuración se rompe en el momento en que cae el túnel.

Luego está el kill switch que bloquea el DNS fuera del túnel. Los nombres se resuelven para las zonas del túnel y fallan en todo lo demás mientras la conexión está perfectamente sana. Las respuestas viables son un permiso explícito para el resolutor de la LAN o una caché local que reenvíe solo la zona corporativa, y cualquiera de las dos es una excepción con dueño y no un defecto del túnel.

Un perfil que reescribe la configuración del resolutor al arrancar la interfaz se comporta casi igual: una vez que el resolutor local es inalcanzable, solo se resolverán los nombres que conoce el túnel. Sea cual sea el mecanismo aplicable, anota qué nombres deben funcionar en cada estado y pasa esa lista a quien atienda los informes.

Verifica por enlace y luego otra vez tras reconectar

Pregunta un nombre interno y uno público, y mira adónde va realmente la consulta. Una página de comprobación de fugas te dice qué resolutor respondió, no qué enlace eligió el sistema, así que no dice nada sobre el orden que acabas de configurar.

Ejecuta las dos consultas otra vez tras desconectar y reconectar. Las prioridades se vuelven a aplicar cuando una conexión se activa, y un enlace simbólico viejo puede sobrevivir a una actualización que nadie recuerda. Lo que quieres dejar escrito al final es qué resolutor es dueño de qué sufijo, más una comprobación que siga valiendo mañana.