Ihr VPN schiebt drei DNS-Server: Welcher antwortet?

Öffnen Sie nach dem Verbinden die Einstellungsseite, und dort stehen drei DNS-Adressen; die Prüfungsfrage ist, welche davon Ihre letzte Abfrage bearbeitet hat. Die Zahl allein beantwortet nichts, denn ein Client-Push, eine physische Schnittstelle und eine Richtlinie pro Domäne schreiben alle in dieselbe Ansicht. Diese Einträge tragen unterschiedliche Geltungsbereiche, und der Bereich statt der Position entscheidet, wer antwortet. Trennen Sie zuerst die Quellen, und testen Sie dann diejenige, der der Name gehört, der Sie interessiert.

Warum die Liste länger ist als Ihr Profil

Ein VPN-Client schiebt Resolver-Adressen für die Tunnelverbindung, und das Betriebssystem behält sie neben dem, was die physische Schnittstelle bereits hatte. Ein Router, ein Firmen-DHCP-Lease, ein zweites VPN und eine Richtlinie pro Domäne tragen jeweils einen eigenen Eintrag bei. Drei Adressen auf der Seite können daher drei Geltungsbereiche bedeuten statt drei Kandidaten für eine Aufgabe. Die Zahl als Beweis für ein Leck zu lesen, ist der erste Fehler dieser Prüfung.

Innerhalb einer Schnittstelle probiert ein Client seine Server tatsächlich der Reihe nach, eine geordnete Liste ist also nicht bedeutungslos. Was keine Warteschlange ist, ist die zusammengeführte Ansicht, in der Einträge aus dem Profil, der physischen Verbindung und Regeln pro Domäne ohne eine einzige Rangfolge nebeneinander stehen. Diese Unterscheidung bestimmt, was Sie testen: Die Reihenfolge erklärt das Verhalten innerhalb eines Bereichs, und der Bereich erklärt alles andere.

Verschlüsseltes DNS bricht das Bild aus einer Anwendung heraus. Ein Browser oder Chat-Client mit eigenem DNS-over-HTTPS-Resolver schickt Abfragen völlig an der Liste des Betriebssystems vorbei, sodass die Adressen auf der Einstellungsseite Verkehr beschreiben, den die Anwendung nie erzeugt hat. Prüfen Sie die eigene Resolver-Einstellung der Anwendung, bevor Sie dem Profil einen falsch aufgelösten Namen anlasten.

Was jede der drei Prüfungen zeigt

Jede Quelle hinterlässt ihre Spur an einer anderen Stelle, und kein einzelner Befehl zeigt alle. Diese Zuordnung gehört neben die Einstellungsseite:

Auf einem System mit systemd-resolved ist resolvectl status maßgeblich, weil es DNS pro Verbindung zusammen mit den Routing-Domänen meldet. macOS antwortet über scutil --dns, das bereichsgebundene Resolver in der Reihenfolge ihres Versuchs auflistet. Windows teilt die beiden Hälften: Get-DnsClientServerAddress für Server pro Schnittstelle und Get-DnsClientNrptPolicy für die Suffixregeln. Führen Sie den Befehl aus, der zum tatsächlich verwendeten Resolver gehört, denn ein Rechner mit Container-Laufzeit und Desktop-Resolver kann mehr als einen installiert haben.

Ein Ersatz-Resolver, der Ihre Zone nicht beantworten kann

Ein zweiter Eintrag ist normalerweise für die Verfügbarkeit da, und Verfügbarkeit funktioniert nur, wenn der Ersatz die Namen kennt. Fragen Sie einen öffentlichen Resolver nach einem internen Hostnamen, und er liefert NXDOMAIN oder eine Wildcard-Antwort aus einer Suchdomäne, die nichts mit Ihnen zu tun hat. Ein ungeprüftes Failover erzeugt dann einen Ausfall genau in dem Moment, in dem es gebraucht wird.

Split DNS existiert, um das zu verhindern: Firmensuffixe gehen an einen Resolver, der die Zone hält, und öffentliche Namen bleiben auf dem Standardpfad. Das Design ist solide, und es hängt davon ab, dass die Suffixliste vollständig ist. Microsoft dokumentiert die Resolver-Richtlinie pro Suffix, die dies unter Windows steuert, und dieselbe Idee erscheint als Routing-Domänen in systemd-resolved und als bereichsgebundene Resolver unter macOS.

Vergleichen Sie die Zonen, die der Ersatz beantworten darf, mit den in der Richtlinie vorhandenen Suffixen. Dieser Vergleich findet die Lücke, bevor ein Nutzer meldet, dass eine interne Seite nach einer Tunneländerung nicht mehr auflöst.

Fragen Sie durch die Richtlinie, nicht daran vorbei

Fragen Sie durch den Resolver des Betriebssystems, denn eine direkte Abfrage an einen Server umgeht die Richtlinie und meldet nur, was dieser Server sagen würde. Die Lücke zwischen den beiden Antworten ist der ganze Punkt:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Wenn die Systemabfrage eine private Adresse zurückgibt, während die direkte Abfrage NXDOMAIN liefert, funktioniert die Richtlinie und der Ersatz ist die Schwachstelle. Wenn beide dieselbe öffentliche Antwort liefern, wird der Name außerhalb des beabsichtigten Bereichs aufgelöst, und die Suffixliste ist der Ort zum Nachsehen. Bewahren Sie beide Ausgaben auf, denn ein Resolver-Streit ist mit zwei Zeilen schneller geklärt als mit einem Screenshot der Einstellungsseite.

Üben Sie dann den Fehlerpfad, denn ein ungetesteter Fallback ist eine Annahme. Machen Sie den bevorzugten Resolver für eine Abfrage zu einem schwarzen Loch und beobachten Sie, welche Adresse zurückkommt:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Löschen Sie diese Route, sobald die Abfrage fertig ist, sonst erbt die nächste Person ein Rätsel. Wenn interne Namen in diesem Fenster weiterhin auflösen, hat etwas außerhalb des beabsichtigten Bereichs sie beantwortet. Wenn sie stattdessen in eine Zeitüberschreitung laufen, fehlt der Fallback oder er ist korrekt begrenzt, und das eigene Protokoll des Resolvers sagt Ihnen, welches von beidem es war.

Entscheiden: behalten, begrenzen oder entfernen

Behalten Sie einen zweiten Resolver, wenn er den benötigten Namensraum beantwortet und unter dem Profil erreichbar bleibt. Begrenzen Sie ihn, wenn er ein Suffix und sonst nichts sehen soll, und entfernen Sie ihn, wenn er weder einen Bereich noch einen dokumentierten Zweck hat. Ein Eintrag ohne Aufgabe ist ein künftiges Leck ohne Nutzen, und eine Herstellervorgabe ist kein Zweck.

Halten Sie das Ergebnis in vier Spalten fest: Suffix, Resolver, Schnittstelle und Verantwortlicher. Diese Zeile beantwortet die nächste Prüfungsfrage schneller als jeder Screenshot, und sie übersteht das Client-Update, das die Liste still umsortiert.