DNS nur über den eigenen VPN-Resolver zulassen: ein Durchlauf

Verfolgen Sie eine einzelne Namensauflösung, sobald Sie sie eintippen: Der Browser fragt das Betriebssystem, das Betriebssystem den Resolver, den seine Richtlinie auswählt, und die Abfrage verlässt den Rechner über irgendeine Schnittstelle und irgendeinen Transport. Ihr VPN-Konzept sagt, die Antwort solle von einem bestimmten Resolver über einen bestimmten Pfad kommen. Die Lücke zwischen diesen Aussagen konfigurieren Sie und erzwingen sie anschließend.

Schritt 1: Resolver und Pfad benennen

Notieren Sie drei Dinge, bevor Sie eine Firewall anfassen: die Resolver-Adresse, das erwartete Protokoll samt Port und die Schnittstelle, über die die Abfrage hinausgehen soll. Ohne diese Liste ist eine Regel eine Vermutung über Datenverkehr statt die Durchsetzung einer Entscheidung. Ein VPN kann Anwendungsdaten tragen, während DNS über eine eigene Regelung läuft; das ist für sich genommen kein Fehler, sondern das Ergebnis davon, dass niemand dem Client etwas anderes gesagt hat.

Den Pfad ausdrücklich zu benennen unterscheidet ein Konzept von einem Zufall. Es gibt Ihnen außerdem etwas zum späteren Testen, weil sich jede Beobachtung mit einer schriftlichen Erwartung vergleichen lässt. Bewahren Sie die Liste im Change-Ticket auf, nicht nur im Kopf.

Schritt 2: Die Richtlinie dort setzen, wo sie lebt

Die Resolver-Auswahl gehört zum Client: Netzwerkkonfiguration des Betriebssystems, Einstellungen des VPN-Clients oder eine verwaltete Browser-Richtlinie. Setzen Sie sie zuerst dort, mit dem Mechanismus der Plattform, denn eine Firewall kann einen Client nicht dazu bringen, einen Resolver zu wählen, von dem er nie erfahren hat. Bei einem Split-Tunnel-Client sagen Sie ausdrücklich, welche Domänen an den internen Resolver gehen. In einem verwalteten Bestand ist eine Browser-Richtlinie oft der einzige Hebel für DoH, weil der Browser seinen verschlüsselten Resolver unabhängig von der Systemeinstellung wählen kann.

Überspringen Sie das und gehen direkt an die Firewall, erhalten Sie eine Regel, die den richtigen Resolver erlaubt, und einen Client, der ihn nie nutzt. Die Regel wirkt korrekt, die Resolver-Protokolle bleiben leer — ein verwirrendes Paar beim Debuggen. Erst die Wahl konfigurieren, dann erzwingen.

Schritt 3: Den Pfad eng erzwingen

Fügen Sie nun die Netzwerkberechtigung für den erlaubten Pfad hinzu: Resolver-Adresse, Protokoll und Port sowie die Schnittstelle, über die er das Gerät verlassen soll. Beschränken Sie die Regel auf diesen Resolver, statt den gesamten ausgehenden DNS-Verkehr zu erlauben. Die drei Pfade unten kann ein moderner Client nehmen, und nur der erste wird von einer Port-53-Regel erfasst.

DoH und DoT zu blockieren ist legitim; anzunehmen, eine Port-53-Regel habe sie bereits blockiert, nicht. Ein Browser mit DoH löst Namen über einen Pfad auf, den Ihre Regel nie beschrieben hat, und eine Anwendung mit eigenem Resolver tut dasselbe. Schreiben Sie jeden Pfad auf, den Sie zulassen, und jeden, den Sie ablehnen wollen. Eine Regel, die keinen Pfad nennt, hat über ihn nicht entschieden.

Schritt 4: Privaten und öffentlichen Namen folgen

Split-DNS schickt bewusst nur private Namensräume an einen internen Resolver, während öffentliche Namen woanders hingehen; mehr als ein Resolver im Konzept ist also kein Leck. Das Leck ist eine Abfrage, die zu Ihrem Resolver hätte gehen sollen und anderswo ankommt, oder ein unerreichbarer beabsichtigter Pfad, der den Client still zurückfallen lässt. Genau diese beiden Fälle suchen Sie. Verfolgen Sie einen internen und einen öffentlichen Namen unter der beabsichtigten Richtlinie und notieren Sie, welcher Resolver jeweils geantwortet hat.

Eine Testseite, die Ihren Resolver anzeigt, ist ein Hinweis, kein Beweis, denn sie sieht nur Abfragen, die sie erreicht haben. Erfassen Sie die Abfrage auf der Clientseite, wenn Sie wissen müssen, welchen Pfad sie tatsächlich genommen hat, und vergleichen Sie beide Beobachtungen. Widersprechen sie sich, haben Sie einen undokumentierten Rückfall gefunden.

Stimmt die Resolver-Adresse, ist aber nicht erreichbar, liegt das Problem in Routing oder Filterung und nicht in der Richtlinie. Verfolgen Sie die Abfrage zu dieser Adresse und bestätigen Sie, dass die Antwort über die erwartete Schnittstelle zurückkommt, bevor Sie eine Resolver-Einstellung ändern.

Schritt 5: Einen Weg zurück offen halten

Bevor Sie den DNS-Zugriff am Gateway verschärfen, bestätigen Sie eine Wiederherstellungsmethode, die nicht von der Namensauflösung abhängt. Ein defekter Resolver macht jedes Reparaturwerkzeug schwerer erreichbar, auch die, mit denen Sie die Änderung zurücknehmen würden. Halten Sie eine lokale Konsole oder einen Out-of-Band-Pfad offen, bis die neue Richtlinie bewiesen ist. Entfernen Sie ihn erst, wenn die Richtlinie einen Reconnect überstanden hat.

Prüfen Sie nach einem Reconnect oder einer Browser-Richtlinien-Aktualisierung den effektiven Zustand erneut, denn beide können den Resolver ändern, ohne Ihre Regel zu ändern. Gefordert sind ein bekannter Empfänger und ein geschützter Pfad für die Abfragen, nicht ein beruhigendes Resolver-Label auf einem Screenshot. Die Spezifikation RFC 8484 für DNS over HTTPS ist die Referenz für den verschlüsselten Pfad, den Ihre Port-Regel nicht sieht.