DNS de WireGuard en iPhone: el dominio solo es un sufijo de búsqueda

Escribes una línea con una dirección de resolutor y un dominio de empresa, esperando que solo los nombres de ese dominio usen el resolutor del túnel. En el cliente de Apple, ahora todos los nombres van allí, y los nombres cortos del dominio también se resuelven. La línea hace dos cosas separadas, y solo una de ellas trata de qué consultas gestiona el túnel. La otra es una comodidad de escritura que una lectura ilusoria ha elevado a política.

En qué se descompone la línea DNS

El cliente lee la entrada como una lista y clasifica cada elemento por su forma. Todo lo que parece una dirección se convierte en un servidor DNS; todo lo que parece un dominio se convierte en un sufijo de búsqueda. Ambos acaban en la configuración del túnel, pero en campos distintos. Una línea ilustrativa para un túnel que lleva un resolutor privado y un dominio interno se ve así.

DNS = 10.24.8.53, lab.internal.example

La dirección proporciona el resolutor. El dominio proporciona un sufijo que permite al cliente escribir un nombre corto y al sistema añadir el resto antes de preguntar. Ninguno de los dos dice nada sobre limitar el resolutor a ese dominio, y esa es justo la parte que la gente espera y no obtiene. Solo un campo de la plataforma puede expresar esa restricción, y no es este.

Dos campos de Apple, dos trabajos distintos

Apple expone la distinción en su objeto de ajustes DNS. La lista de dominios de búsqueda está documentada como la lista que se usa para cualificar nombres de host de una sola etiqueta: escribe un nombre de host desnudo y el sistema puede añadir cada sufijo por turno. Esa es una regla de completado, no una regla de enrutamiento. Nada de esa lista decide qué servidor se consulta.

La lista de dominios de coincidencia es una propiedad distinta. Decide qué espacios de nombres usan este conjunto de ajustes DNS, y una entrada vacía significa el dominio predeterminado en lugar de un sufijo concreto. generador de ajustes del túnel de paquetes en el cliente de Apple sigue ese modelo. Coloca los sufijos de búsqueda analizados en la lista de búsqueda, y cuando hay servidores, establece la lista de coincidencia en la cadena vacía. El resultado es un resolutor de túnel que responde a todo lo que el sistema le envía, más un sufijo que ayuda con los nombres cortos.

Así que un dominio en esa línea no es un selector de espacio de nombres. Añadir otro no restringe qué consultas usa el túnel, y quitarlo tampoco las amplía. Lo único que cambia es cuántos nombres cortos se completan.

Por qué cada nombre sigue llegando al resolutor del túnel

Con la entrada de coincidencia vacía, el túnel es un resolutor candidato para nombres ordinarios, no solo para el dominio de la empresa. En una configuración de túnel completo esto suele importar poco, porque todo el tráfico está en el túnel de todos modos. En un túnel dividido importa mucho. Los nombres públicos ahora pueden ser resueltos por un resolutor que solo tiene una zona privada, y un fallo parece un VPN roto cuando en realidad es un resolutor que responde solo a parte del espacio de nombres. El túnel está bien, las consultas salen y las respuestas vuelven vacías.

Hay dos arreglos disponibles y son decisiones distintas. Convierte el resolutor del túnel en un resolutor completo que reenvíe los nombres públicos por la ruta aprobada, o deja de enviarle nombres públicos cambiando la configuración del cliente en lugar de la lista de dominios. El primero mantiene cada consulta en el túnel y confía en el origen superior. El segundo mantiene algunas consultas locales y acepta que los nombres privados pueden dejar de resolverse mientras el túnel está caído.

Qué necesitaría realmente un DNS dividido

Una política de resolutor limitada a un espacio de nombres requiere un cliente que te permita expresarla: haz coincidir dominios en las plataformas de Apple, o un ajuste equivalente en el producto que uses. Un campo de configuración que solo acepta servidores y sufijos no puede expresarla, por muy bien puntuado que esté. Un perfil puede llevar la política porque describe una configuración gestionada en lugar de una pista en el momento de conectar. Puede nombrar el dominio, los servidores y qué debería pasar cuando ese dominio no sea accesible. Esa es la diferencia entre un ajuste y un contrato.

En los dispositivos Apple gestionados esto suele entregarse mediante un perfil de configuración que lleva los ajustes DNS específicos del dominio. Es un mecanismo distinto del archivo de configuración de WireGuard, y ambos solo pueden coexistir si el cliente respeta el perfil. Comprueba cómo llama realmente tu cliente al campo antes de suponer que los dos productos se comportan igual. Un script con wg-quick en un Mac y la aplicación WireGuard en un iPhone leen líneas parecidas y las instalan a través de capas distintas.

Lee los ajustes instalados, no el archivo

En un Mac puedes inspeccionar con qué acabó el sistema, lo que es más informativo que releer el archivo que escribiste. La lista de resolutores muestra qué servidores están configurados para qué dominios, y las consultas delimitadas muestran cuál ganó. Un cliente que estropea la línea lo muestra aquí en lugar de en el archivo que escribiste. En iOS no hay una línea de comandos equivalente, así que la prueba allí es un resultado: un nombre privado que se resuelve por el túnel y un nombre público cuya respuesta revela qué resolutor contestó.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Estos dos comandos imprimen la configuración actual del resolutor y los servidores DNS del servicio activo. Si el resolutor del túnel aparece como resolutor predeterminado sin restricción de dominio, la configuración hace exactamente lo que pidió el cliente. Corrige eso cambiando el mecanismo, no añadiendo un segundo sufijo y esperando que el comportamiento cambie.