DNS-Resolver-Protokolle vs. VPN-Verbindungsprotokolle: Was jede Aufzeichnung enthält

Ein DNS-Resolver-Protokoll und ein VPN-Verbindungsprotokoll sind beide Netzwerkaufzeichnungen, beide nützlich und nicht austauschbar. Der Resolver empfängt Namen, deren Beantwortung von ihm verlangt wurde. Der VPN-Endpunkt verwaltet Tunnelverbindungen und zeichnet auf, was seine Implementierung darüber aufzuzeichnen beschlossen hat. Sie können im selben Gebäude stehen, von demselben Team betrieben werden und unter dieselbe Datenschutzerklärung fallen, und dennoch beschreiben sie unterschiedliche Ereignisse mit unterschiedlichen Kennungen und unterschiedlicher Aufbewahrung. Das eine zu lesen, als wäre es das andere, ist der Weg, auf dem Ermittlungen schiefgehen.

Zwei Protokolle, zwei Ereignisse

Ein Resolver-Eintrag beantwortet eine Frage zur Namensauflösung: Dieser Client fragte zu dieser Zeit nach diesem Namen, und die Antwort war diese. Ein VPN-Eintrag beantwortet eine Frage zur Konnektivität: Dieser Peer baute einen Tunnel auf oder verlor ihn, erhielt diese Adresse und übertrug ungefähr so viele Daten, bevor er verschwand. Keiner von beiden ist eine Aufzeichnung dessen, was der Nutzer innerhalb einer HTTPS-Sitzung getan hat, und keiner ersetzt den anderen.

Der Unterschied hat eine praktische Folge für Versprechen. Die Aussage, ein VPN-Anbieter protokolliere keine Tunnelaktivität, sagt nichts über den Resolver, den er ausliefert, und die Aufbewahrungsrichtlinie eines Resolvers sagt nichts darüber, wer sich mit dem Tunnel verbunden hat. Jede Behauptung gehört zu ihrem eigenen Betreiber und ihrem eigenen System.

Verfolgen Sie die Abfrage, bevor Sie eines der beiden Protokolle lesen

Eine Abfrage erreicht einen Resolver nur, wenn der Pfad ihn tatsächlich fragt. Eine Anwendung kann den Resolver des Betriebssystems nutzen, ihren eigenen verschlüsselten DNS-Client ausführen oder eine zwischengespeicherte Antwort lesen und nie etwas senden. Ein Resolver-Protokoll, das nichts zeigt, ist also kein Beweis dafür, dass ein Name nie verwendet wurde; es ist ein Beweis dafür, dass dieser Resolver nicht gefragt wurde.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Der letzte Befehl liest das eigene Journal des lokalen Resolvers, was nicht dasselbe ist wie das Protokoll des vorgelagerten Servers. Wenn Ihre Abfragen über DNS over HTTPS zu einem Anbieter hinausgehen, zeigt der lokale Stub möglicherweise nichts, während der Anbieter die vollständige Aufzeichnung hat, und der Anbieter ist ein anderer Betreiber mit einer anderen Richtlinie.

Was jede Aufzeichnung zeigen kann und was nicht

Sie zu verknüpfen ist die eigentliche Arbeit, und sie zu verknüpfen ist nicht immer möglich. Ein Resolver, der Client-Adressen protokolliert, lässt sich mit einem VPN vergleichen, das Adressen aus einem bekannten Pool vergibt, und dieser Vergleich erzeugt eine plausible Verbindung zwischen einem abgefragten Namen und einem Tunnel, die eine Verbindung zwischen zwei Aufzeichnungen bleibt und keine Aufzeichnung über eine Person ist.

Verschlüsseltes DNS ändert den Transport, nicht die Sichtbarkeit am Endpunkt. Der Resolver empfängt weiterhin die Frage, die er beantwortet, wie RFC 8484 deutlich macht, und die Aufbewahrung bei diesem Resolver ist eine Richtlinienentscheidung und keine Eigenschaft des Protokolls.

Wo Split-DNS und Caches die Geschichte verwirren

Mehrere Resolver sind normal. Ein Split-DNS-Design schickt interne Namen an einen internen Server und alles andere an einen öffentlichen, sodass eine einzelne Untersuchung zwei Protokolle umfassen kann, die nie zur Kombination gedacht waren, und zwei Aufbewahrungseinstellungen, die nie zum Vergleich gedacht waren. Abfragen bei beiden zu sehen, ist ein Beweis dafür, dass das Design funktioniert, nicht für ein Leck.

Caches schneiden in die andere Richtung. Ein beliebter Name kann stundenlang aus dem Cache beantwortet werden, sodass die Aufzeichnung des Resolvers die erste Abfrage und dann nichts zeigt, während die Anwendung des Nutzers denselben Namen weiterhin munter auflöst. Das Fehlen von Einträgen nach einer bestimmten Zeit bedeutet nicht, dass niemand den Namen nach dieser Zeit verwendet hat.

Hintergrundverkehr ist die dritte Verzerrung. Ein Telefon, das beim Start einen Telemetrienamen auflöst, ein Browser, der eine Suchvorschlagsdomain auflöst, und ein Updater, der sich stündlich meldet, erscheinen alle in einem Resolver-Protokoll neben dem Namen, der Ihnen wirklich wichtig ist. Volumen in diesem Protokoll ist keine Aufmerksamkeit, und Abfragen zu zählen ist nicht, Besuche zu zählen. Ein Resolver-Protokoll ist eine Aufzeichnung von Fragen, und Fragen lassen sich billig erzeugen.

Stellen Sie die Aufbewahrungsfragen getrennt

Stellen Sie für jedes System drei Fragen: Wer erhebt, was wird erhoben und wie lange es aufbewahrt wird. Fragen Sie dann, wer es lesen darf und in welchem Verfahren. Die Erörterung von RFC 8484 zu DNS over HTTPS ist eine gute Erinnerung daran, dass verschlüsselter Transport den Endpunkt nicht beseitigt, und die eigene Dokumentation eines Betreibers ist die einzige verlässliche Aussage darüber, was dieser Endpunkt aufbewahrt.

Wenn eine Aussage zum Datenschutz über „das VPN“ gemacht wird, zerlegen Sie sie in Komponenten, bevor Sie sie annehmen: den Tunnelbetreiber, den Resolver, den der Tunnel ausliefert, jeden vorgelagerten Resolver, den diese Abfragen erreichen, und die Anwendungen auf dem Gerät. Jede hat ihre eigene Antwort, und eine für eine zutreffende Aussage wird routinemäßig wiederholt, als decke sie alle vier ab.

Verwenden Sie zur Fehlersuche dieselbe Aufteilung. Fragen Sie, welche Anwendung die Abfrage gestellt hat und welcher Resolver sie beantwortet hat, und sehen Sie dann in dem Protokoll nach, dem dieses Ereignis tatsächlich gehört. Aus dem anderen Protokoll zu raten spart eine Minute und kostet einen Nachmittag.