Cómo inspeccionar los resolutores DNS que usa tu Mac en una VPN

scutil --dns imprime la configuración del resolutor que macOS consulta realmente, no el único servidor DNS que escribiste en un panel de ajustes. La salida es más larga de lo que la mayoría espera, porque el sistema mantiene bloques de resolutor separados para la ruta predeterminada, para interfaces con ámbito y para reenvío específico de dominios. El bloque de la parte superior del volcado no es necesariamente el que responde a la consulta. Si un nombre privado se resuelve en la oficina y falla en el momento en que la VPN sube, el desajuste está en las reglas de coincidencia y las rutas, no en la dirección del servidor. Lee primero el orden y luego demuestra la respuesta con una consulta real.

Lee el orden de los bloques antes que las direcciones

Cada entrada abre con resolver #N y enumera nameserver[0], a veces if_index, una línea flags, reach y, cuando el bloque no es un valor predeterminado simple, un domain y una lista search domain. El resolutor número 1 sin dominio es el predeterminado que atiende nombres públicos. Todo lo que lleve Scoped en sus indicadores está ligado a la interfaz que nombra if_index, y todo lo marcado como Supplemental se aplica solo a los dominios enumerados debajo.

La selección es coincidencia de sufijo. Para un nombre como intranet.corp.example, macOS prefiere el resolutor cuya entrada domain es el sufijo coincidente más largo, así que un bloque con domain : corp.example gana al predeterminado incluso cuando está muy abajo en la salida. order desempata entre dominios de la misma longitud. Un primer vistazo rara vez necesita más: toda la salida cuando quieres leer un bloque de principio a fin, las primeras líneas para aprender el orden de los bloques y una pasada filtrada que imprime las cabeceras de bloque junto a las líneas de campo. Los bloques con ámbito aparecen bajo su propia cabecera y se leen como una continuación de la lista de arriba, así que mantén una cabecera a la vista siempre que cites la salida.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Asocia if_index a la interfaz del túnel

Un índice solo es útil si puedes nombrar la interfaz que hay detrás. scutil --nwi enumera la información de red que mantiene el sistema, incluida la interfaz principal y la accesibilidad, mientras que ifconfig -l te da los nombres, donde utun0 hasta utun9 son los candidatos a túnel que un cliente suele crear. Apple usa scutil --dns como su propio ejemplo de inspección en la guía de despliegue, y documenta cómo Network Extension puede enrutar dominios seleccionados a resolutores seleccionados, que es el mecanismo que exponen esos bloques con ámbito.

La comprobación que zanja la cuestión es si el resolutor está en la ruta que instaló el túnel:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Si route -n get devuelve una puerta de enlace y una interfaz que no coinciden con la entrada del resolutor, la dirección puede ser perfectamente correcta y aun así inalcanzable. Un túnel dividido que solo lleva las subredes corporativas descarta las consultas dirigidas a un servidor DNS fuera de ellas, y el fallo se manifiesta como un tiempo de espera, por eso el volcado de configuración sigue pareciendo limpio.

Consulta el resolutor del sistema y luego el servidor

Tres herramientas responden a tres preguntas distintas, y confundirlas produce la mayoría de las conclusiones erróneas en esta área. dscacheutil -q host -a name pasa por el mismo resolutor del sistema que usan las aplicaciones normales, así que se aplican los bloques con ámbito y suplementarios. dig sin argumento de servidor lee /etc/resolv.conf, que no es la fuente de verdad para la resolución con ámbito en macOS, y se salta por completo las reglas por dominio. dig @address llega exactamente a un servidor y no te dice nada sobre la selección.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Cuando el primer comando responde y el segundo devuelve NXDOMAIN, has encontrado la división que buscabas y nada está roto. Cuando el primero agota el tiempo mientras dig @10.20.0.53 responde, el resolutor funciona pero no es alcanzable en la ruta que eligió el túnel, así que el siguiente paso es route -n get y no una edición de los ajustes de DNS. Mantén los nombres privados fuera de todo lo que pegues en un ticket o una nota compartida.

Lo que el volcado no puede mostrarte

Varias capas se sientan encima o al lado de la lista de resolutores, y cada una puede enviar una consulta a un lugar que el volcado nunca menciona. Un navegador con DNS seguro activado puede resolver por su propio canal cifrado, así que una página que carga mientras dscacheutil agota el tiempo no es una contradicción. Un proxy DNS instalado por software de seguridad se ejecuta como proveedor de Network Extension y reenvía las consultas él mismo, y scutil --dns muestra lo que se configuró y no la dirección de origen que el proxy acabó usando. Los dominios de búsqueda añaden una tercera arruga: a un nombre no cualificado se le añade cada sufijo enumerado por orden, así que el bloque que respondió puede ser uno que nunca sospechaste.

Las respuestas obsoletas son lo más barato de descartar y lo que más a menudo se omite:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Si la salida cambia tras el vaciado, el estado estaba en caché y el volcado anterior describía un túnel que ya no existía. Si no cambia, la configuración es la que es, y la pregunta pasa a las rutas y a la política de aplicaciones.

Un runbook breve para antes y después

Captura una línea base solo donde la política lo permita, y mantén los archivos fuera de cualquier carpeta sincronizada. La secuencia de abajo es la que ejecuto en máquinas de clientes: captura la línea base, conecta, captura otra vez, y luego compara y busca.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Lee la diferencia por bloques en vez de por líneas. Un resolutor con ámbito nuevo que lleve el índice de la interfaz del túnel y una entrada domain para el sufijo privado es la forma esperada. Un resolutor predeterminado nuevo que apunte a una dirección pública es un hallazgo que merece plantearse a quien posea el perfil del cliente. Luego repite la consulta dentro de la aplicación que realmente falló, no solo en el intérprete de órdenes, y anota la interfaz de route -n get junto al resultado.

Para deshacer un cambio, desconecta y repite la captura de la línea base. Si el bloque con ámbito ha desaparecido, el cliente ha limpiado tras de sí. Si el bloque sigue listado contra una interfaz que ya no existe, el estado está obsoleto, y un vaciado más una reconexión es el arreglo más suave antes de que nadie toque el perfil.

Cuatro comprobaciones, en este orden: ¿coincide algún bloque de resolutor con el sufijo más largo del nombre; está ese bloque ligado a la interfaz que instaló el túnel; usa la ruta hacia su servidor de nombres el túnel; y devuelve la respuesta el resolutor del sistema, no dig. La primera comprobación que falla te dice si cambiar la política de DNS, las rutas del túnel o la aplicación. Si las cuatro pasan y el nombre sigue fallando, el problema está por encima del DNS, y lo siguiente que hay que inspeccionar es lo que responda al puerto 53 delante de él.