Jak zkontrolovat DNS resolvery, které váš Mac používá na VPN

scutil --dns vypisuje konfiguraci resolveru, kterou macOS skutečně používá, ne ten jediný DNS server, který jste zadali do panelu nastavení. Výstup je delší, než většina lidí čeká, protože systém drží oddělené bloky resolveru pro výchozí cestu, pro rozsahová rozhraní a pro přesměrování podle domén. Blok na začátku výstupu nemusí být ten, který odpovídá na dotaz. Pokud se soukromé jméno v kanceláři přeloží a ve chvíli, kdy se VPN zvedne, přestane fungovat, nesoulad je v pravidlech párování a v trasách, ne v adrese serveru. Přečtěte nejdřív pořadí a pak odpověď dokažte skutečným dotazem.

Přečtěte pořadí bloků dřív než adresy

Každý záznam začíná resolver #N a vypisuje nameserver[0], někdy if_index, řádek flags, reach a když blok není obyčejná výchozí hodnota, také domain a seznam search domain. Resolver číslo 1 bez domény je výchozí, který obsluhuje veřejná jména. Cokoli nese ve svých příznacích Scoped, je vázáno na rozhraní pojmenované v if_index, a cokoli označené Supplemental platí jen pro domény uvedené pod ním.

Výběr je párování přípon. Pro jméno jako intranet.corp.example dává macOS přednost resolveru, jehož záznam domain je nejdelší odpovídající přípona, takže blok s domain : corp.example porazí výchozí i tehdy, když stojí hluboko ve výstupu. order rozhoduje shody mezi doménami stejné délky. První pohled málokdy potřebuje víc: celý výstup, když chcete jeden blok přečíst od začátku do konce, úvodní řádky k poznání pořadí bloků a filtrovaný průchod, který vypisuje záhlaví bloků vedle řádků polí. Rozsahové bloky se objevují pod vlastním nadpisem a čtou se jako pokračování seznamu nad nimi, proto mějte nadpis na očích, kdykoli výstup citujete.

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'

Přiřaďte if_index k rozhraní tunelu

Index je užitečný jen tehdy, když dokážete pojmenovat rozhraní za ním. scutil --nwi vypisuje síťové informace, které systém drží, včetně primárního rozhraní a dostupnosti, zatímco ifconfig -l vám dá jména, kde utun0 až utun9 jsou kandidáti na tunel, které klient obvykle vytváří. Apple používá scutil --dns jako svůj vlastní příklad kontroly v průvodci nasazením, a dokumentuje, jak Network Extension může směrovat vybrané domény na vybrané resolvery, což je mechanismus, který tyto rozsahové bloky odhalují.

Kontrola, která otázku rozhodne, je, zda resolver leží na cestě, kterou tunel nainstaloval:

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

Pokud route -n get vrátí bránu a rozhraní, které neodpovídají záznamu resolveru, adresa může být naprosto správná a přesto nedostupná. Rozdělený tunel, který nese jen firemní podsítě, zahazuje dotazy mířené na DNS server mimo ně a selhání se projeví jako vypršení času, proto výstup konfigurace pořád vypadá čistě.

Ptejte se systémového resolveru, pak serveru

Tři nástroje odpovídají na tři různé otázky a jejich záměna produkuje většinu chybných závěrů v této oblasti. dscacheutil -q host -a name jde přes stejný systémový resolver, který používají běžné aplikace, takže rozsahové a doplňkové bloky platí. dig bez argumentu serveru čte /etc/resolv.conf, což není zdroj pravdy pro rozsahové překlady na macOS, a pravidla pro jednotlivé domény úplně přeskakuje. dig @address dosáhne přesně jednoho serveru a o výběru neřekne nic.

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

Když první příkaz odpoví a druhý vrátí NXDOMAIN, našli jste rozdělení, které jste hledali, a nic není rozbité. Když první vyprší, zatímco dig @10.20.0.53 odpovídá, resolver funguje, ale není dostupný na cestě, kterou tunel zvolil, takže dalším krokem je route -n get, ne úprava nastavení DNS. Držte soukromá jména mimo cokoli, co vkládáte do tiketu nebo sdílené poznámky.

Co vám výstup nemůže ukázat

Nad seznamem resolverů nebo vedle něj sedí několik vrstev a každá může poslat dotaz někam, co výstup nikdy nezmíní. Prohlížeč se zapnutým zabezpečeným DNS může překládat přes svůj vlastní šifrovaný kanál, takže stránka, která se načte, zatímco dscacheutil vyprší, není protiklad. DNS proxy nainstalovaná bezpečnostním softwarem běží jako poskytovatel Network Extension a dotazy předává sama a scutil --dns ukazuje, co bylo nakonfigurováno, ne adresu proti proudu, kterou proxy nakonec použila. Domény hledání přidávají třetí záhyb: k nekvalifikovanému jménu se v pořadí přidává každá uvedená přípona, takže blok, který odpověděl, může být takový, jaký jste vůbec netušili.

Zastaralé odpovědi se vylučují nejlevněji a přeskakují se nejčastěji:

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

Pokud se výstup po vyčištění změní, stav byl v cache a dřívější výstup popisoval tunel, který už neexistoval. Pokud se nezmění, konfigurace je taková, jaká je, a otázka se přesouvá k trasám a k politice aplikací.

Krátký runbook pro před a po

Zachyťte výchozí stav jen tam, kde to politika dovoluje, a držte soubory mimo jakoukoli synchronizovanou složku. Postup níže je to, co spouštím na klientských strojích: zachyťte výchozí stav, připojte se, zachyťte znovu, pak porovnejte a hledejte.

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

Čtěte rozdíl po blocích, ne po řádcích. Nový rozsahový resolver nesoucí index rozhraní tunelu a záznam domain pro soukromou příponu je očekávaný tvar. Nový výchozí resolver ukazující na veřejnou adresu je zjištění, které stojí za to nadnést tomu, kdo vlastní profil klienta. Pak zopakujte dotaz uvnitř aplikace, která skutečně selhala, ne jen v shellu, a poznamenejte rozhraní z route -n get vedle výsledku.

Chcete-li změnu vrátit, odpojte se a zopakujte zachycení výchozího stavu. Pokud rozsahový blok zmizel, klient po sobě uklidil. Pokud je blok stále uveden proti rozhraní, které už neexistuje, stav je zastaralý, a vyčištění plus opětovné připojení je nejšetrnější oprava, než někdo sáhne na profil.

Čtyři kontroly v tomto pořadí: odpovídá nějaký blok resolveru nejdelší příponě jména; je tento blok vázán na rozhraní, které tunel nainstaloval; používá trasa k jeho jmennému serveru tunel; a vrací odpověď systémový resolver, ne dig. První kontrola, která selže, vám řekne, zda změnit DNS politiku, trasy tunelu, nebo aplikaci. Pokud projdou všechny čtyři a jméno stále selhává, problém je nad DNS a další věc ke kontrole je cokoli, co před ním odpovídá na port 53.