Com inspeccionar els resolutors DNS que fa servir el teu Mac en una VPN

scutil --dns imprimeix la configuració del resolutor que macOS consulta realment, no el servidor DNS únic que vas escriure en un tauler de preferències. La sortida és més llarga del que la majoria espera, perquè el sistema manté blocs de resolutor separats per al camí per defecte, per a interfícies amb abast i per a reenviament específic de dominis. El bloc del capdamunt de la sortida no és necessàriament el que respon la consulta. Si un nom privat es resol a l’oficina i falla en el moment en què la VPN s’aixeca, el desajust és a les regles de coincidència i a les rutes, no a l’adreça del servidor. Llegeix primer l’ordre i després demostra la resposta amb una consulta real.

Llegeix l’ordre dels blocs abans que les adreces

Cada entrada comença amb resolver #N i llista nameserver[0], de vegades if_index, una línia flags, reach i, quan el bloc no és un simple valor per defecte, un domain i una llista search domain. El resolutor número 1 sense domini és el valor per defecte que gestiona noms públics. Tot el que porti Scoped als seus indicadors està lligat a la interfície que anomena if_index, i tot el que estigui marcat Supplemental s’aplica només als dominis llistats sota seu.

La selecció és coincidència de sufix. Per a un nom com intranet.corp.example, macOS prefereix el resolutor l’entrada domain del qual és el sufix coincident més llarg, així que un bloc amb domain : corp.example guanya el valor per defecte fins i tot quan és molt avall a la sortida. order desfà els empats entre dominis de la mateixa longitud. Una primera ullada poques vegades necessita més que això: tota la sortida quan vols llegir un bloc de cap a cap, les primeres línies per aprendre l’ordre dels blocs i una passada filtrada que imprimeix les capçaleres dels blocs al costat de les línies de camps. Els blocs amb abast apareixen sota el seu propi encapçalament i es llegeixen com una continuació de la llista de sobre, així que tingues una capçalera a la vista sempre que citis la sortida.

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'

Relaciona if_index amb la interfície del túnel

Un índex només és útil si pots anomenar la interfície que hi ha darrere. scutil --nwi llista la informació de xarxa que manté el sistema, incloent la interfície principal i l’abastabilitat, mentre que ifconfig -l et dona els noms, on utun0 fins a utun9 són els candidats a túnel que un client normalment crea. Apple fa servir scutil --dns com el seu propi exemple d’inspecció a la guia de desplegament, i documenta com Network Extension pot encaminar dominis seleccionats cap a resolutors seleccionats, que és el mecanisme que exposen aquests blocs amb abast.

La comprovació que resol la qüestió és si el resolutor seua al camí que el túnel ha instal·lat:

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

Si route -n get retorna una passarel·la i una interfície que no coincideixen amb l’entrada del resolutor, l’adreça pot ser perfectament correcta i tot i així inabastable. Un túnel dividit que només porta les subxarxes corporatives descarta les consultes adreçades a un servidor DNS fora d’elles, i la fallada es manifesta com un temps d’espera exhaurit, i per això la sortida de configuració continua semblant neta.

Consulta el resolutor del sistema i després el servidor

Tres eines responen tres preguntes diferents, i confondre-les produeix la majoria de conclusions errònies en aquesta àrea. dscacheutil -q host -a name passa pel mateix resolutor del sistema que fan servir les aplicacions normals, així que els blocs amb abast i suplementaris s’apliquen. dig sense argument de servidor llegeix /etc/resolv.conf, que no és la font de veritat per a la resolució amb abast a macOS, i s’salta completament les regles per domini. dig @address arriba exactament a un servidor i no et diu res sobre la selecció.

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

Quan la primera ordre respon i la segona retorna NXDOMAIN, has trobat la divisió que buscaves i no hi ha res trencat. Quan la primera exhaureix el temps mentre dig @10.20.0.53 respon, el resolutor funciona però no és abastable pel camí que el túnel ha triat, així que el següent pas és route -n get i no una edició de la configuració DNS. Mantingues els noms privats fora de qualsevol cosa que enganxis en un tiquet o una nota compartida.

Què no et pot mostrar la sortida

Diverses capes seuen damunt o al costat de la llista de resolutors, i cadascuna pot enviar una consulta en un lloc que la sortida no esmenta mai. Un navegador amb DNS segur activat pot resoldre pel seu propi canal xifrat, així que una pàgina que carrega mentre dscacheutil exhaureix el temps no és cap contradicció. Un proxy DNS instal·lat per programari de seguretat s’executa com a proveïdor de Network Extension i reenvia les consultes ell mateix, i scutil --dns mostra què es va configurar i no l’adreça d’origen que el proxy va acabar fent servir. Els dominis de cerca afegeixen una tercera complicació: a un nom no qualificat se li afegeix cada sufix llistat per ordre, així que el bloc que va respondre pot ser un que mai no vas sospitar.

Les respostes obsoletes són el més barat de descartar i el que més sovint s’omet:

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

Si la sortida canvia després del buidatge, l’estat era a la memòria cau i la sortida anterior descrivia un túnel que ja no existia. Si no canvia, la configuració és la que és, i la pregunta es trasllada a les rutes i a la política d’aplicacions.

Un manual breu per a abans i després

Captura una línia de base només on la política ho permeti, i mantingues els fitxers fora de qualsevol carpeta sincronitzada. La seqüència de sota és la que executo en màquines de clients: captura la línia de base, connecta, torna a capturar, i després compara i 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

Llegeix la diferència per blocs i no per línies. Un resolutor amb abast nou que porti l’índex de la interfície del túnel i una entrada domain per al sufix privat és la forma esperada. Un resolutor per defecte nou que apunti a una adreça pública és una troballa que val la pena plantejar a qui posseeix el perfil del client. Després repeteix la consulta dins de l’aplicació que realment va fallar, no només a l’intèrpret d’ordres, i anota la interfície de route -n get al costat del resultat.

Per desfer un canvi, desconnecta i repeteix la captura de la línia de base. Si el bloc amb abast ha desaparegut, el client ha netejat després de si mateix. Si el bloc encara apareix llistat contra una interfície que ja no existeix, l’estat és obsolet, i un buidatge més una reconnexió és l’arranjament més suau abans que ningú toqui el perfil.

Quatre comprovacions, en aquest ordre: algun bloc de resolutor coincideix amb el sufix més llarg del nom; aquest bloc està lligat a la interfície que el túnel ha instal·lat; la ruta fins al seu servidor de noms fa servir el túnel; i el resolutor del sistema, i no dig, retorna la resposta. La primera comprovació que falla et diu si cal canviar la política DNS, les rutes del túnel o l’aplicació. Si les quatre passen i el nom encara falla, el problema se situa per damunt del DNS, i la propera cosa a inspeccionar és qualsevol cosa que respongui al port 53 davant seu.