Como inspeccionar os resolutores DNS que usa o teu Mac nunha VPN

scutil --dns imprime a configuración do resolutor que macOS consulta realmente, non o único servidor DNS que escribiches nun panel de axustes. A saída é máis longa do que a maioría espera, porque o sistema mantén bloques de resolutor separados para a ruta predeterminada, para interfaces con ámbito e para reenvío específico de dominios. O bloque da parte superior da saída non é necesariamente o que responde á consulta. Se un nome privado se resolve na oficina e falla no momento en que a VPN sobe, o desaxuste está nas regras de coincidencia e nas rutas, non no enderezo do servidor. Le primeiro a orde e logo demostra a resposta cunha consulta real.

Le a orde dos bloques antes dos enderezos

Cada entrada abre con resolver #N e enumera nameserver[0], ás veces if_index, unha liña flags, reach e, cando o bloque non é un simple predeterminado, un domain e unha lista search domain. O resolutor número 1 sen dominio é o predeterminado que atende nomes públicos. Todo o que leve Scoped nos seus indicadores está ligado á interface que nomea if_index, e todo o marcado como Supplemental aplícase só aos dominios enumerados debaixo.

A selección é coincidencia de sufixo. Para un nome como intranet.corp.example, macOS prefire o resolutor cuxa entrada domain é o sufixo coincidente máis longo, así que un bloque con domain : corp.example gaña ao predeterminado mesmo cando está moi abaixo na saída. order desempata entre dominios da mesma lonxitude. Unha primeira ollada raramente necesita máis: toda a saída cando queres ler un bloque de principio a fin, as primeiras liñas para aprender a orde dos bloques e unha pasada filtrada que imprime as cabeceiras dos bloques xunto ás liñas de campo. Os bloques con ámbito aparecen baixo a súa propia cabeceira e lese como unha continuación da lista de arriba, así que mantén unha cabeceira á vista sempre que cites a saída.

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 á interface do túnel

Un índice só é útil se podes nomear a interface que hai detrás. scutil --nwi enumera a información de rede que mantén o sistema, incluída a interface principal e a accesibilidade, mentres que ifconfig -l dache os nomes, onde utun0 ata utun9 son os candidatos a túnel que un cliente adoita crear. Apple usa scutil --dns como o seu propio exemplo de inspección na guía de despregamento, e documenta como Network Extension pode encamiñar dominios seleccionados a resolutores seleccionados, que é o mecanismo que expoñen eses bloques con ámbito.

A comprobación que resolve a cuestión é se o resolutor está na ruta que instalou o túnel:

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

Se route -n get devolve unha pasarela e unha interface que non coinciden coa entrada do resolutor, o enderezo pode ser perfectamente correcto e aínda así inalcanzable. Un túnel dividido que só leva as subredes corporativas descarta as consultas dirixidas a un servidor DNS fóra delas, e o fallo maniféstase como un tempo de espera, por iso a saída de configuración segue parecendo limpa.

Consulta o resolutor do sistema e logo o servidor

Tres ferramentas responden a tres preguntas distintas, e confundilas produce a maioría das conclusións erróneas nesta área. dscacheutil -q host -a name pasa polo mesmo resolutor do sistema que usan as aplicacións normais, así que se aplican os bloques con ámbito e suplementarios. dig sen argumento de servidor le /etc/resolv.conf, que non é a fonte de verdade para a resolución con ámbito en macOS, e salta por completo as regras por dominio. dig @address chega exactamente a un servidor e non che di nada sobre a 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

Cando o primeiro comando responde e o segundo devolve NXDOMAIN, atopaches a división que buscabas e nada está roto. Cando o primeiro esgota o tempo mentres dig @10.20.0.53 responde, o resolutor funciona pero non é alcanzable na ruta que escolleu o túnel, así que o seguinte paso é route -n get e non unha edición dos axustes de DNS. Mantén os nomes privados fóra de calquera cousa que pegues nun ticket ou nunha nota compartida.

O que a saída non che pode mostrar

Varias capas sentan enriba ou ao lado da lista de resolutores, e cada unha pode enviar unha consulta a un lugar que a saída nunca menciona. Un navegador con DNS seguro activado pode resolver pola súa propia canle cifrada, así que unha páxina que carga mentres dscacheutil esgota o tempo non é unha contradición. Un proxy DNS instalado por software de seguridade execútase como provedor de Network Extension e reenvía as consultas el mesmo, e scutil --dns mostra o que se configurou e non o enderezo de orixe que o proxy acabou usando. Os dominios de busca engaden unha terceira engurra: a un nome non cualificado engádeselle cada sufixo enumerado por orde, así que o bloque que respondeu pode ser un que nunca sospeitaches.

As respostas obsoletas son o máis barato de descartar e o que máis a miúdo se omite:

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

Se a saída cambia tras o baleirado, o estado estaba na caché e a saída anterior describía un túnel que xa non existía. Se non cambia, a configuración é a que é, e a pregunta trasládase ás rutas e á política de aplicacións.

Un runbook breve para antes e despois

Captura unha liña base só onde a política o permita, e mantén os ficheiros fóra de calquera cartafol sincronizado. A secuencia de abaixo é a que executo en máquinas de clientes: captura a liña base, conecta, captura outra vez, e logo compara e 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

Le a diferenza por bloques en vez de por liñas. Un resolutor con ámbito novo que leve o índice da interface do túnel e unha entrada domain para o sufixo privado é a forma esperada. Un resolutor predeterminado novo que apunte a un enderezo público é un achado que merece plantexarse a quen posúa o perfil do cliente. Logo repite a consulta dentro da aplicación que realmente fallou, non só na consola, e anota a interface de route -n get xunto ao resultado.

Para desfacer un cambio, desconecta e repite a captura da liña base. Se o bloque con ámbito desapareceu, o cliente limpou tras de si. Se o bloque segue listado contra unha interface que xa non existe, o estado está obsoleto, e un baleirado máis unha reconexión é o arranxo máis suave antes de que ninguén toque o perfil.

Catro comprobacións, nesta orde: coincide algún bloque de resolutor co sufixo máis longo do nome; está ese bloque ligado á interface que instalou o túnel; usa a ruta cara ao seu servidor de nomes o túnel; e devolve a resposta o resolutor do sistema, non dig. A primeira comprobación que falla diche se cambiar a política de DNS, as rutas do túnel ou a aplicación. Se as catro pasan e o nome segue fallando, o problema está por riba do DNS, e o seguinte que hai que inspeccionar é o que responda ao porto 53 diante del.