Så här kontrollerar du DNS-resolvarna som din Mac använder på en VPN

scutil --dns skriver ut den resolverkonfiguration som macOS faktiskt använder, inte den enda DNS-server du skrev in i en inställningspanel. Utskriften är längre än de flesta förväntar sig, eftersom systemet håller separata resolverblock för standardvägen, för avgränsade gränssnitt och för domänspecifik vidarebefordran. Blocket överst i utskriften är inte nödvändigtvis det som svarar på frågan. Om ett privat namn slås upp på kontoret och misslyckas i samma stund som VPN:en kommer upp, ligger avvikelsen i matchningsreglerna och rutterna, inte i serveradressen. Läs ordningen först och bevisa sedan svaret med en riktig uppslagning.

Läs blockordningen före adresserna

Varje post öppnas med resolver #N och listar nameserver[0], ibland if_index, en flags-rad, reach och, när blocket inte är en vanlig standard, en domain och en search domain-lista. Resolvern nummer 1 utan domän är standarden som hanterar offentliga namn. Allt som bär Scoped i sina flaggor är bundet till gränssnittet som if_index namnger, och allt märkt Supplemental gäller bara för de domäner som listas under det.

Valet är suffixmatchning. För ett namn som intranet.corp.example föredrar macOS den resolver vars domain-post är det längsta matchande suffixet, så ett block med domain : corp.example slår standarden även när det står långt ner i utskriften. order avgör oavgjorda fall mellan domäner av samma längd. En första blick behöver sällan mer: hela utskriften när du vill läsa ett block från början till slut, de första raderna för att lära dig blockordningen och en filtrerad genomgång som skriver ut blockrubrikerna bredvid fältraderna. Avgränsade block visas under sin egen rubrik och läses som en fortsättning av listan ovanför, så håll en rubrik i sikte när du citerar utskriften.

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'

Koppla if_index till tunnelgränssnittet

Ett index är bara användbart om du kan namnge gränssnittet bakom det. scutil --nwi listar nätverksinformationen systemet håller, inklusive det primära gränssnittet och nåbarhet, medan ifconfig -l ger dig namnen, där utun0 till utun9 är tunnelkandidaterna som en klient vanligtvis skapar. Apple använder scutil --dns som sitt eget inspektionsexempel i distributionsguiden, och dokumenterar hur Network Extension kan dirigera valda domäner till valda resolvare, vilket är mekanismen som dessa avgränsade block avslöjar.

Den kontroll som avgör frågan är om resolvern sitter på den väg som tunneln installerade:

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

Om route -n get returnerar en gateway och ett gränssnitt som inte matchar resolverposten kan adressen vara helt korrekt och ändå onåbar. En delad tunnel som bara bär företagets subnät släpper frågor riktade mot en DNS-server utanför dem, och felet visar sig som en timeout, vilket är varför konfigurationsutskriften fortfarande ser ren ut.

Fråga systemresolvern, sedan servern

Tre verktyg svarar på tre olika frågor, och att bland dem ger de flesta felaktiga slutsatserna i det här området. dscacheutil -q host -a name går genom samma systemresolver som vanliga program använder, så avgränsade och kompletterande block gäller. dig utan serverargument läser /etc/resolv.conf, vilket inte är sanningskällan för avgränsad uppslagning på macOS, och det hoppar helt över reglerna per domän. dig @address når exakt en server och säger ingenting om valet.

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

När det första kommandot svarar och det andra returnerar NXDOMAIN har du hittat delningen du letade efter och ingenting är trasigt. När det första får timeout medan dig @10.20.0.53 svarar fungerar resolvern men är inte nåbar på den väg tunneln valde, så nästa steg är route -n get i stället för en ändring av DNS-inställningarna. Håll privata namn borta från allt du klistrar in i ett ärende eller ett delat anteckning.

Vad utskriften inte kan visa dig

Flera lager sitter ovanför eller bredvid resolverlistan, och vart och ett kan skicka en fråga någonstans som utskriften aldrig nämner. En webbläsare med säker DNS aktiverad kan slå upp via sin egen krypterade kanal, så en sida som laddas medan dscacheutil får timeout är inte en motsägelse. En DNS-proxy som installeras av säkerhetsprogramvara kör som en Network Extension-leverantör och vidarebefordrar frågorna själv, och scutil --dns visar vad som konfigurerades, inte den uppströmsadress som proxyn till slut använde. Sökdomäner lägger till en tredje krusning: ett okvalificerat namn får varje listat suffix tillagt i ordning, så blocket som svarade kan vara ett du aldrig misstänkte.

Föråldrade svar är det billigaste att utesluta och det som oftast förbises:

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

Om utskriften ändras efter tömningen var tillståndet cachat och den tidigare utskriften beskrev en tunnel som inte längre fanns. Om den inte ändras är konfigurationen som den är, och frågan flyttar till rutter och till programpolicy.

En kort körbok för före och efter

Ta en baslinje bara där policyn tillåter det, och håll filerna utanför varje synkroniserad mapp. Sekvensen nedan är den jag kör på klientmaskiner: ta baslinjen, anslut, ta igen och jämför sedan och slå upp.

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

Läs skillnaden per block i stället för per rad. En ny avgränsad resolver som bär tunnelgränssnittets index och en domain-post för det privata suffixet är den förväntade formen. En ny standardresolver som pekar på en offentlig adress är ett fynd som är värt att lyfta med den som äger klientprofilen. Upprepa sedan uppslagningen i det program som faktiskt misslyckades, inte bara i skalet, och anteckna gränssnittet från route -n get bredvid resultatet.

För att ångra en ändring kopplar du från och upprepar baslinjeinspelningen. Om det avgränsade blocket är borta har klienten städat efter sig. Om blocket fortfarande listas mot ett gränssnitt som inte längre finns, är tillståndet föråldrat, och en tömning plus en återanslutning är den mildaste åtgärden innan någon rör profilen.

Fyra kontroller i denna ordning: matchar ett resolverblock namnets längsta suffix; är det blocket bundet till gränssnittet som tunneln installerade; använder rutten till dess namnserver tunneln; och returnerar systemresolvern, inte dig, svaret. Den första kontroll som misslyckas säger om du ska ändra DNS-policyn, tunnelrutterna eller programmet. Om alla fyra passerar och namnet ändå misslyckas sitter problemet ovanför DNS, och nästa sak att undersöka är allt som svarar på port 53 framför det.