Hoe om die DNS-resolvers na te gaan wat jou Mac op ’n VPN gebruik

scutil --dns druk die resolver-konfigurasie wat macOS werklik raadpleeg, nie die enkele DNS-bediener wat jy in ’n instellingspaneel ingetik het nie. Die uitset is langer as wat die meeste mense verwag, want die stelsel hou afsonderlike resolver-blokke vir die verstekpad, vir scoped-koppelvlakke en vir domeinspesifieke aanstuur. Die blok boaan die uitset is nie noodwendig die een wat die navraag beantwoord nie. As ’n private naam by die kantoor oplos en die oomblik misluk wanneer die VPN opkom, lê die wanpassing in die passingreëls en roetes, nie in die bedieneradres nie. Lees eers die volgorde en bewys dan die antwoord met ’n werklike opsoek.

Lees die blokvolgorde voor die adresse

Elke inskrywing begin met resolver #N en lys nameserver[0], soms if_index, ’n flags-reël, reach, en, wanneer die blok nie ’n gewone verstek is nie, ’n domain en ’n search domain-lys. Resolver #1 sonder ’n domein is die verstek wat openbare name hanteer. Enigiets met Scoped in sy vlagte is gebind aan die koppelvlak wat if_index noem, en enigiets gemerk Supplemental geld net vir die domeine wat daaronder gelys word.

Keuse is agtervoegsel-passing. Vir ’n naam soos intranet.corp.example verkies macOS die resolver wie se domain-inskrywing die langste passende agtervoegsel is, so ’n blok met domain : corp.example wen teen die verstek selfs wanneer dit ver onder in die uitset staan. order breek gelykheid tussen domeine van dieselfde lengte. ’n Eerste blik het selde meer nodig as dit: die hele uitset wanneer jy een blok van begin tot einde wil lees, die eerste reëls om die blokvolgorde te leer, en ’n gefiltreerde deurloop wat die blokkoppe langs die veldreëls druk. Scoped-blokke verskyn onder hul eie opskrif en lees soos ’n voortsetting van die lys bokant hulle, so hou ’n kop in sig wanneer jy die uitset aanhaal.

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'

Pas if_index by die tonnel-koppelvlak aan

’n Indeks is net nuttig as jy die koppelvlak agter hom kan noem. scutil --nwi lys die netwerkinligting wat die stelsel hou, insluitend die primêre koppelvlak en bereikbaarheid, terwyl ifconfig -l vir jou die name gee, waar utun0 tot utun9 die tonnelkandidate is wat ’n kliënt gewoonlik skep. Apple gebruik scutil --dns as sy eie inspeksievoorbeeld in die ontplooiingsgids, en dokumenteer hoe Network Extension geselekteerde domeine na geselekteerde resolvers kan lei, wat die meganisme is wat daardie scoped-blokke blootlê.

Die toets wat die vraag besleg, is of die resolver op die pad sit wat die tonnel geïnstalleer het:

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

Gee route -n get ’n deurgang en koppelvlak terug wat nie by die resolver-inskrywing pas nie, kan die adres heeltemal korrek en tog onbereikbaar wees. ’n Gesplete tonnel wat net die korporatiewe subnette dra, laat navrae na ’n DNS-bediener buite hulle val, en die fout wys as ’n tydsverloop, daarom lyk die konfigurasie-uitset steeds skoon.

Vra die stelselresolver, dan die bediener

Drie gereedskapstukke beantwoord drie verskillende vrae, en om hulle te verwar lewer die meeste verkeerde gevolgtrekkings in hierdie gebied. dscacheutil -q host -a name gaan deur dieselfde stelselresolver wat gewone programme gebruik, so scoped- en aanvullende blokke geld. dig sonder ’n bediener-argument lees /etc/resolv.conf, wat nie die waarheidsbron vir scoped-resolusie op macOS is nie, en dit slaan die per-domein-reëls heeltemal oor. dig @address bereik presies een bediener en sê niks oor keuse nie.

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

Wanneer die eerste opdrag antwoord en die tweede NXDOMAIN teruggee, het jy die splitsing gevind waarna jy gesoek het en niks is stukkend nie. Wanneer die eerste uittyd terwyl dig @10.20.0.53 antwoord, werk die resolver maar is dit nie bereikbaar op die pad wat die tonnel gekies het nie, so die volgende stap is route -n get eerder as ’n wysiging aan DNS-instellings. Hou private name uit enigiets wat jy in ’n kaartjie of ’n gedeelde nota plak.

Wat die uitset jou nie kan wys nie

Verskeie lae sit bo of langs die resolver-lys, en elkeen kan ’n navraag stuur na ’n plek wat die uitset nooit noem nie. ’n Blaaier met veilige DNS geaktiveer kan oor sy eie geënkripteerde kanaal resolveer, so ’n bladsy wat laai terwyl dscacheutil uittyd, is nie ’n teenstrydigheid nie. ’n DNS-proxy wat deur sekuriteitsagteware geïnstalleer is, loop as ’n Network Extension-verskaffer en stuur navrae self aan, en scutil --dns wys wat gekonfigureer is eerder as die opstroom-adres wat die proxy uiteindelik gebruik het. Soekdomeine voeg ’n derde kinkel by: ’n ongekwalifiseerde naam kry elke gelyste agtervoegsel in volgorde bygevoeg, so die blok wat geantwoord het kan een wees wat jy nooit vermoed het nie.

Verouderde antwoorde is die goedkoopste ding om uit te skakel en die mees gereeld oorgeslane:

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

Verander die uitset ná die skoonmaak, was die toestand gekas en het die vroeëre uitset ’n tonnel beskryf wat nie meer bestaan het nie. Verander dit nie, is die konfigurasie wat dit is, en skuif die vraag na roetes en na toepassingsbeleid.

’n Kort draaiboek vir voor en ná

Neem ’n basislyn slegs waar beleid dit toelaat, en hou die lêers uit enige gesinkroniseerde vouer. Die volgorde hieronder is wat ek op kliëntmasjiene hardloop: neem die basislyn, koppel, neem weer, en vergelyk dan en soek op.

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

Lees die verskil per blok eerder as per reël. ’n Nuwe scoped-resolver wat die tonnelkoppelvlak-indeks en ’n domain-inskrywing vir die private agtervoegsel dra, is die verwagte vorm. ’n Nuwe verstekresolver wat na ’n openbare adres wys, is ’n bevinding wat die moeite werd is om op te bring by wie ook al die kliëntprofiel besit. Herhaal dan die opsoek binne die toepassing wat werklik gefaal het, nie net in die dop nie, en noteer die koppelvlak van route -n get langs die resultaat.

Om ’n verandering ongedaan te maak, ontkoppel en herhaal die basislyn-opname. As die scoped-blok weg is, het die kliënt na homself opgeruim. As die blok steeds gelys is teen ’n koppelvlak wat nie meer bestaan nie, is die toestand verouderd, en ’n skoonmaak plus ’n herkoppeling is die sagste oplossing voordat iemand die profiel aanraak.

Vier kontroles, in hierdie volgorde: pas ’n resolver-blok by die langste agtervoegsel van die naam; is daardie blok gebind aan die koppelvlak wat die tonnel geïnstalleer het; gebruik die roete na sy naamserver die tonnel; en gee die stelselresolver, nie dig nie, die antwoord terug. Die eerste kontrole wat faal, sê vir jou of jy DNS-beleid, die tonnelroetes of die toepassing moet verander. Slaag al vier en faal die naam steeds, sit die probleem bo DNS, en die volgende ding om te ondersoek is wat ook al poort 53 voor hom beantwoord.