DNSSEC oder VPN: Was verbirgt Ihre DNS-Abfragen?

Zwei Mechanismen bekommen dieselbe Aufgabe zugeschrieben, und keiner von beiden erfüllt sie. DNSSEC beantwortet, ob die Daten, die Sie erhalten haben, wirklich von der Zone stammen, die sie veröffentlicht, und ein VPN entscheidet, welchen Weg Ihre Pakete nehmen. Keiner von beiden verbirgt den Namen, nach dem Sie gefragt haben, in jedem Fall, und die Einstellungen, die so aussehen, als müssten sie das tun, betreffen meist den Transport oder das Routing und nicht die Validierung. Wenn Sie zuerst die Schicht benennen, wird aus einer vagen Datenschutzfrage eine konkrete.

Drei Aussagen, die zu einer verschmelzen

Authentizität ist die Aussage, dass die Antwort die ist, die die Zone veröffentlicht hat, und unterwegs nicht verändert wurde. Vertraulichkeit ist die Aussage, dass niemand auf dem Weg die Abfrage oder die Antwort lesen kann. Routing ist die Aussage, dass die Pakete einem von Ihnen gewählten Weg folgen, und genau das leistet ein Tunnel.

DNSSEC behandelt die erste und sagt nichts über die anderen beiden. DoT und DoH behandeln die zweite für den Sprung zum Resolver. Ein VPN behandelt die dritte und kann auch die zweite beeinflussen, aber nur als Nebenwirkung davon, wohin der Datenverkehr geht.

Anwendungsverkehr ist ein vierter Fall: HTTPS schützt und authentifiziert den Web-Austausch zwischen Ihrem Client und der Website, und keine DNS-Schicht ersetzt das.

Was Signaturvalidierung kann und was nicht

Ein validierender Resolver prüft die Signaturkette von der Zone bis zu einem konfigurierten Vertrauensanker und gibt dann eine Antwort mit gesetztem Flag für authentifizierte Daten zurück, wenn die Prüfung gelingt. Dieses Flag ist ein Beweis über die Daten, nicht über die Verbindung oder die Absichten des Ziels.

Er kann einen rechtmäßigen Zoneninhaber nicht daran hindern, authentische Einträge für einen Dienst zu veröffentlichen, dem Sie nicht vertrauen sollten. Eine korrekt signierte Antwort aus einer kompromittierten Domain ist weiterhin korrekt signiert, und DNSSEC hat keine Meinung dazu, ob diese Domain Ihre Zugangsdaten verdient.

Er verbirgt auch nichts. Abfrage und Antwort durchqueren das Netz in einer Form, die ein Resolver und jeder Beobachter auf diesem Weg lesen können, sofern nicht eine andere Schicht den Transport schützt. Eine signierte Antwort und eine private Antwort sind verschiedene Eigenschaften, und ein Deployment kann jede für sich allein haben. Testen Sie beides, wenn Ihnen eines davon wichtig ist.

Woher Vertraulichkeit tatsächlich kommt

Verschlüsselter Resolver-Transport packt den DNS-Austausch in TLS, sodass der Resolver die Frage weiterhin sieht, der Weg zwischen Ihnen und ihm aber nicht. Das verschiebt Vertrauen, statt es zu beseitigen: Sie vertrauen dem Resolver mehr und dem lokalen Netz weniger.

Ein VPN kann Abfragen zu einem Resolver auf der anderen Seite tragen, was sowohl den Weg als auch den Resolver ändert, der sie sieht. Das ist eine Routingentscheidung mit Datenschutzfolge, und in einem verwalteten Netz kann der interne Resolver der einzige sein, der interne Namen beantworten kann.

Die Kombination, die Menschen tatsächlich wollen, sind meist drei Dinge gleichzeitig: Validierung an, verschlüsselter Transport zu einem selbst gewählten Resolver und Anwendungs-TLS am Ziel. Jede ist unabhängig, und eine auszulassen hinterlässt eine andere Lücke.

Validierung und Transport getrennt prüfen

Zwei Tests klären den größten Teil der Verwirrung. Der erste fragt, ob der Resolver die Antwort validiert hat; der zweite fragt, ob der Transport geschützt war. Sie scheitern auf unterschiedliche Weise, und keiner impliziert den anderen.

Diese Befehle geben die Flags einer validierenden Abfrage aus, wiederholen die Abfrage mit deaktivierter Prüfung und führen die lokale Validierung mit delv durch:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Eine Antwort mit dem Flag für authentifizierte Daten und einer vorhandenen Signatur zeigt Validierung bei diesem Resolver. Ein Validierungsfehler mit delv zeigt eine gebrochene Kette irgendwo zwischen der Zone und dem Vertrauensanker, was ein Veröffentlichungsproblem und kein Tunnelproblem ist. Eine Zeitüberschreitung ganz ohne Flags ist ein Transport- oder Erreichbarkeitsproblem, und sie als Signaturfehler zu behandeln schickt Sie auf die falsche Schicht.

Was tun, wenn ein VPN die Auflösung kaputt macht

Wenn die Auflösung vor dem Tunnel funktionierte und danach aufhört, vergleichen Sie den Resolver, den jeder Weg verwendet. Split-Tunneling, ein interner Resolver, der nur über den Tunnel erreichbar ist, und ein Client, der Resolver-Einstellungen überschreibt, ändern alle die Antwort, ohne DNSSEC zu berühren.

Validierung global zu deaktivieren ist der falsche erste Schritt, weil er den einzigen Mechanismus entfernt, der Manipulation meldet, und einen nicht erreichbaren Resolver nicht repariert. Grenzen Sie den Fehler zuerst ein: Auflösung, Transport, Validierung, dann Richtlinie. Nur das dritte gehört zu DNSSEC, und nur das zweite gehört zu verschlüsseltem Transport.