Sådan undersøger du de DNS-resolvere, din Mac bruger på en VPN

scutil --dns udskriver den resolver-konfiguration, macOS faktisk bruger, ikke den ene DNS-server, du skrev ind i et indstillingspanel. Outputtet er længere, end de fleste forventer, fordi systemet holder separate resolver-blokke til standardstien, til afgrænsede grænseflader og til domænespecifik videresendelse. Blokken øverst i outputtet er ikke nødvendigvis den, der besvarer forespørgslen. Hvis et privat navn slår op på kontoret og fejler i det øjeblik, VPN’et kommer op, ligger uoverensstemmelsen i matchningsregler og ruter, ikke i serveradressen. Læs rækkefølgen først, og bevis derefter svaret med et rigtigt opslag.

Læs blokrækkefølgen før adresserne

Hver post åbner med resolver #N og lister nameserver[0], nogle gange if_index, en flags-linje, reach, og når blokken ikke er en almindelig standard, en domain og en search domain-liste. Resolver nummer 1 uden domæne er standarden, der håndterer offentlige navne. Alt med Scoped i sine flag er bundet til den grænseflade, som if_index navngiver, og alt markeret Supplemental gælder kun for de domæner, der er listet under det.

Valget er suffiksmatchning. For et navn som intranet.corp.example foretrækker macOS den resolver, hvis domain-post er det længste matchende suffiks, så en blok med domain : corp.example vinder over standarden, selv når den står langt nede i outputtet. order bryder uafgjorte forhold mellem domæner af samme længde. Et første kig har sjældent brug for mere: hele outputtet, når du vil læse en blok fra ende til anden, de første linjer for at lære blokrækkefølgen, og et filtreret gennemløb, der udskriver blokoverskrifterne ved siden af feltlinjerne. Afgrænsede blokke vises under deres egen overskrift og læses som en fortsættelse af listen ovenover, så hold en overskrift i syne, når du citerer outputtet.

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'

Knyt if_index til tunnelgrænsefladen

Et indeks er kun nyttigt, hvis du kan navngive grænsefladen bag det. scutil --nwi lister den netværksinformation, systemet holder, inklusive den primære grænseflade og tilgængelighed, mens ifconfig -l giver dig navnene, hvor utun0 til utun9 er tunnelkandidaterne, som en klient normalt opretter. Apple bruger scutil --dns som sit eget inspektions-eksempel i implementeringsguiden, og dokumenterer, hvordan Network Extension kan rute udvalgte domæner til udvalgte resolvere, hvilket er den mekanisme, de afgrænsede blokke afslører.

Den kontrol, der afgør spørgsmålet, er, om resolveren ligger på den sti, tunnelen installerede:

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

Hvis route -n get returnerer en gateway og en grænseflade, der ikke matcher resolver-posten, kan adressen være helt korrekt og stadig utilgængelig. En delt tunnel, der kun bærer de virksomhedsinterne subnets, dropper forespørgsler rettet mod en DNS-server uden for dem, og fejlen viser sig som en timeout, og derfor ser konfigurationsoutputtet stadig rent ud.

Spørg systemets resolver, derefter serveren

Tre værktøjer besvarer tre forskellige spørgsmål, og forvirring af dem giver de fleste forkerte konklusioner på dette område. dscacheutil -q host -a name går gennem den samme systemresolver, som almindelige programmer bruger, så afgrænsede og supplerende blokke gælder. dig uden serverargument læser /etc/resolv.conf, som ikke er sandhedskilden for afgrænset opslag på macOS, og det springer reglerne pr. domæne helt over. dig @address når præcis én server og fortæller intet om valget.

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 den første kommando svarer, og den anden returnerer NXDOMAIN, har du fundet den deling, du ledte efter, og intet er i stykker. Når den første timer ud, mens dig @10.20.0.53 svarer, virker resolveren, men den er ikke tilgængelig på den sti, tunnelen valgte, så næste skridt er route -n get i stedet for en ændring af DNS-indstillingerne. Hold private navne ude af alt, hvad du sætter ind i en ticket eller et delt notat.

Hvad outputtet ikke kan vise dig

Flere lag ligger over eller ved siden af resolver-listen, og hver af dem kan sende en forespørgsel et sted hen, som outputtet aldrig nævner. En browser med sikker DNS aktiveret kan slå op over sin egen krypterede kanal, så en side, der indlæses, mens dscacheutil timer ud, er ikke en modsætning. En DNS-proxy installeret af sikkerhedssoftware kører som en Network Extension-udbyder og videresender selv forespørgsler, og scutil --dns viser, hvad der blev konfigureret, ikke den upstream-adresse, som proxyen endte med at bruge. Søgedomæner tilføjer en tredje krølle: et ukvalificeret navn får hvert listet suffiks tilføjet i rækkefølge, så den blok, der svarede, kan være en, du aldrig havde mistanke om.

Forældede svar er det billigste at udelukke og det oftest oversete:

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

Hvis outputtet ændrer sig efter flush, var tilstanden cachet, og det tidligere output beskrev en tunnel, der ikke længere fandtes. Hvis det ikke ændrer sig, er konfigurationen, som den er, og spørgsmålet flytter til ruter og til applikationspolitik.

En kort kørebog for før og efter

Optag en baseline kun, hvor politikken tillader det, og hold filerne ude af enhver synkroniseret mappe. Sekvensen nedenfor er den, jeg kører på klientmaskiner: optag baselinen, opret forbindelse, optag igen, og sammenlign derefter og slå 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

Læs forskellen pr. blok i stedet for pr. linje. En ny afgrænset resolver, der bærer tunnelgrænsefladens indeks og en domain-post for det private suffiks, er den forventede form. En ny standardresolver, der peger på en offentlig adresse, er et fund, der er værd at rejse over for den, der ejer klientprofilen. Gentag derefter opslaget inde i det program, der faktisk fejlede, ikke kun i shellen, og noter grænsefladen fra route -n get ved siden af resultatet.

For at fortryde en ændring skal du afbryde forbindelsen og gentage baseline-optagelsen. Hvis den afgrænsede blok er væk, har klienten ryddet op efter sig selv. Hvis blokken stadig er listet mod en grænseflade, der ikke længere findes, er tilstanden forældet, og en flush plus en genopkobling er den blideste løsning, før nogen rører profilen.

Fire kontroller i denne rækkefølge: matcher en resolver-blok navnets længste suffiks; er den blok bundet til den grænseflade, tunnelen installerede; bruger ruten til dens navneserver tunnelen; og returnerer systemets resolver, ikke dig, svaret. Den første kontrol, der fejler, fortæller dig, om du skal ændre DNS-politikken, tunnelruterne eller programmet. Hvis alle fire består, og navnet stadig fejler, sidder problemet over DNS, og det næste, der skal undersøges, er hvad som helst, der svarer på port 53 foran det.