So prüfen Sie die DNS-Resolver, die Ihr Mac in einem VPN nutzt

scutil --dns gibt die Resolver-Konfiguration aus, die macOS tatsächlich heranzieht, nicht den einen DNS-Server, den Sie in ein Einstellungsfenster eingetragen haben. Die Ausgabe ist länger, als die meisten erwarten, weil das System getrennte Resolver-Blöcke für den Standardpfad, für bereichsbezogene Schnittstellen und für domänenspezifische Weiterleitung führt. Der oberste Block der Ausgabe ist nicht zwangsläufig der, der die Abfrage beantwortet. Löst sich ein privater Name im Büro auf und scheitert in dem Moment, in dem das VPN hochkommt, liegt die Abweichung in den Zuordnungsregeln und Routen, nicht in der Serveradresse. Lesen Sie zuerst die Reihenfolge und belegen Sie dann die Antwort mit einer echten Abfrage.

Lesen Sie die Blockreihenfolge vor den Adressen

Jeder Eintrag beginnt mit resolver #N und listet nameserver[0], manchmal if_index, eine flags-Zeile, reach und, wenn der Block kein einfacher Standard ist, eine domain und eine search domain-Liste. Resolver 1 ohne Domäne ist der Standard, der öffentliche Namen bearbeitet. Alles, was Scoped in seinen Flags trägt, ist an die Schnittstelle gebunden, die if_index benennt, und alles mit Supplemental gilt nur für die darunter aufgeführten Domänen.

Die Auswahl ist Suffix-Zuordnung. Für einen Namen wie intranet.corp.example bevorzugt macOS den Resolver, dessen domain-Eintrag das längste passende Suffix ist, sodass ein Block mit domain : corp.example den Standard schlägt, selbst wenn er weit unten in der Ausgabe steht. order entscheidet Gleichstände zwischen Domänen gleicher Länge. Ein erster Blick braucht selten mehr: die ganze Ausgabe, wenn Sie einen Block von Anfang bis Ende lesen wollen, die ersten Zeilen, um die Blockreihenfolge zu lernen, und ein gefilterter Durchlauf, der die Blockköpfe neben den Feldzeilen ausgibt. Bereichsbezogene Blöcke erscheinen unter ihrer eigenen Überschrift und lesen sich wie eine Fortsetzung der Liste darüber, halten Sie also eine Überschrift im Blick, wann immer Sie die Ausgabe zitieren.

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'

if_index der Tunnel-Schnittstelle zuordnen

Ein Index nützt nur, wenn Sie die dahinterliegende Schnittstelle benennen können. scutil --nwi listet die Netzwerkinformationen auf, die das System hält, einschließlich der primären Schnittstelle und der Erreichbarkeit, während ifconfig -l Ihnen die Namen gibt, wobei utun0 bis utun9 die Tunnelkandidaten sind, die ein Client normalerweise anlegt. Apple verwendet scutil --dns als eigenes Inspektionsbeispiel im Bereitstellungsleitfaden, und dokumentiert, wie Network Extension ausgewählte Domänen an ausgewählte Resolver leiten kann, was genau der Mechanismus ist, den diese bereichsbezogenen Blöcke offenlegen.

Die Prüfung, die die Frage entscheidet, ist, ob der Resolver auf dem Pfad sitzt, den der Tunnel installiert hat:

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

Gibt route -n get ein Gateway und eine Schnittstelle zurück, die nicht zum Resolver-Eintrag passen, kann die Adresse völlig richtig und dennoch unerreichbar sein. Ein geteilter Tunnel, der nur die Unternehmens-Subnetze führt, verwirft Abfragen an einen DNS-Server außerhalb davon, und der Fehler zeigt sich als Zeitüberschreitung, weshalb die Konfigurationsausgabe weiterhin sauber aussieht.

Fragen Sie den System-Resolver, dann den Server

Drei Werkzeuge beantworten drei verschiedene Fragen, und ihre Verwechslung erzeugt die meisten Fehlschlüsse in diesem Bereich. dscacheutil -q host -a name geht über denselben System-Resolver, den gewöhnliche Anwendungen nutzen, sodass bereichsbezogene und ergänzende Blöcke gelten. dig ohne Serverargument liest /etc/resolv.conf, was für bereichsbezogene Auflösung unter macOS nicht die Quelle der Wahrheit ist, und überspringt die Regeln pro Domäne vollständig. dig @address erreicht genau einen Server und sagt nichts über die Auswahl.

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

Antwortet der erste Befehl und der zweite liefert NXDOMAIN, haben Sie die gesuchte Trennung gefunden und nichts ist kaputt. Läuft der erste in eine Zeitüberschreitung, während dig @10.20.0.53 antwortet, funktioniert der Resolver, ist aber auf dem vom Tunnel gewählten Pfad nicht erreichbar, also ist der nächste Schritt route -n get statt einer Änderung der DNS-Einstellungen. Halten Sie private Namen aus allem heraus, was Sie in ein Ticket oder eine geteilte Notiz einfügen.

Was die Ausgabe Ihnen nicht zeigen kann

Mehrere Schichten sitzen über oder neben der Resolver-Liste, und jede kann eine Abfrage irgendwohin schicken, was die Ausgabe nie erwähnt. Ein Browser mit aktiviertem sicheren DNS löst möglicherweise über seinen eigenen verschlüsselten Kanal auf, sodass eine Seite, die lädt, während dscacheutil in eine Zeitüberschreitung läuft, kein Widerspruch ist. Ein von Sicherheitssoftware installierter DNS-Proxy läuft als Network-Extension-Anbieter und leitet Abfragen selbst weiter, und scutil --dns zeigt, was konfiguriert wurde, nicht die Upstream-Adresse, die der Proxy letztlich verwendet hat. Suchdomänen fügen eine dritte Eigenheit hinzu: an einen unqualifizierten Namen wird jedes aufgeführte Suffix der Reihe nach angehängt, sodass der Block, der geantwortet hat, einer sein kann, den Sie nie vermutet hätten.

Veraltete Antworten sind das Billigste, was man ausschließen kann, und das am häufigsten Übersehene:

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

Ändert sich die Ausgabe nach dem Leeren, war der Zustand zwischengespeichert und die frühere Ausgabe beschrieb einen Tunnel, den es nicht mehr gab. Ändert sie sich nicht, ist die Konfiguration so, wie sie ist, und die Frage wandert zu Routen und zur Anwendungsrichtlinie.

Ein kurzes Runbook für vorher und nachher

Erfassen Sie eine Grundlinie nur dort, wo die Richtlinie es erlaubt, und halten Sie die Dateien aus jedem synchronisierten Ordner heraus. Die folgende Reihenfolge ist das, was ich auf Client-Rechnern ausführe: Grundlinie erfassen, verbinden, erneut erfassen, dann vergleichen und nachschlagen.

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

Lesen Sie den Unterschied blockweise statt zeilenweise. Ein neuer bereichsbezogener Resolver, der den Schnittstellenindex des Tunnels und einen domain-Eintrag für das private Suffix trägt, ist die erwartete Form. Ein neuer Standard-Resolver, der auf eine öffentliche Adresse zeigt, ist ein Befund, den man demjenigen melden sollte, dem das Client-Profil gehört. Wiederholen Sie dann die Abfrage in der Anwendung, die tatsächlich versagt hat, nicht nur in der Shell, und notieren Sie die Schnittstelle aus route -n get neben dem Ergebnis.

Um eine Änderung rückgängig zu machen, trennen Sie die Verbindung und wiederholen Sie die Grundlinien-Erfassung. Ist der bereichsbezogene Block verschwunden, hat der Client hinter sich aufgeräumt. Steht der Block noch gegen eine Schnittstelle, die es nicht mehr gibt, ist der Zustand veraltet, und ein Leeren plus eine neue Verbindung ist die sanfteste Reparatur, bevor jemand das Profil anfasst.

Vier Prüfungen in dieser Reihenfolge: passt ein Resolver-Block auf das längste Suffix des Namens; ist dieser Block an die Schnittstelle gebunden, die der Tunnel installiert hat; nutzt die Route zu seinem Namensserver den Tunnel; und liefert der System-Resolver, nicht dig, die Antwort. Die erste Prüfung, die scheitert, sagt Ihnen, ob Sie die DNS-Richtlinie, die Tunnelrouten oder die Anwendung ändern müssen. Bestehen alle vier und der Name scheitert weiterhin, sitzt das Problem über DNS, und das Nächste, was zu prüfen ist, ist alles, was davor auf Port 53 antwortet.