Zusammenfassung

  • Eine authentisierte, verschlüsselte DNS-Sitzung belegt Eigenschaften der Verbindung zum Resolver, nicht dessen Umgang mit der entschlüsselten Anfrage.
  • Die in RFC 8932 entworfene RPS macht Betreiberangaben vergleichbar; Transport, Verarbeitung, Speicherung/Zugriff und Weitergabe benötigen trotzdem eigene, zeitlich begrenzte Nachweise.

Auf einem fremden WLAN baut ein Notebook nicht mehr die übliche offene DNS-Verbindung auf. Es authentisiert einen ausgewählten Resolver und sendet seine Fragen über TLS, HTTPS oder QUIC. Der Betreiber des lokalen Netzes kann die Namen nicht mehr ohne Weiteres mitlesen, ein Angreifer auf dieser Strecke nicht so leicht Antworten einschleusen. Das ist ein erheblicher Gewinn.

Doch am Ziel endet die Verschlüsselung. Der rekursive Resolver muss die Anfrage verarbeiten, im Cache suchen, eine Antwort validieren oder andere Server befragen. Sein Betreiber kann grundsätzlich den Namen und Transportkennungen sehen. Er entscheidet über Protokollfelder im Log, Aufbewahrungsdauer, Zugriffsrechte, Verknüpfung mehrerer Sitzungen, Antwortfilter und Informationen in nachgelagerten Anfragen.

RFC 8932, Recommendations for DNS Privacy Service Operators, hält genau diese Grenze offen. Das Dokument erschien im Oktober 2020 als BCP 232 und nennt Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij und Allison Mankin als Autoren. Dickinsons IETF-Profil führt acht RFCs auf, darunter RFC 8932 und RFC 9250 zu DNS über QUIC, und nennt sie als Vorsitzende der Privacy Enhancements and Assessments Research Group. RIPE Labs beschreibt sie als Mitgründerin von Sinodun IT. Diese Quellen belegen eine kollektive fachliche Arbeit, nicht die alleinige Erfindung verschlüsselten DNS oder die Kontrolle fremder Resolver.

Neben Betriebsempfehlungen führt RFC 8932 die Recursive operator Privacy Statement ein, kurz RPS. Betreiber sollen darin ihre Datenschutzversprechen und ihre gegenwärtige Praxis in einer vergleichbaren Gliederung offenlegen. So lässt sich unterscheiden, was behauptet und was gemessen wird. Eine RPS ist weder universelle Vorgabe noch Rechtsberatung noch automatisch ein Prüfsiegel.

Der erste Nachweis betrifft die Verbindung vom Client zum Resolver. Er kann Zielendpunkt und Authentisierungsnamen, Protokoll, Zertifikatsergebnis, TLS- oder QUIC-Version, Padding, Verfügbarkeit und das Verhalten bei Ausfällen festhalten. RFC 8310 behandelt Nutzungsprofile für DNS over TLS, RFC 8484 DNS over HTTPS und RFC 9250 dedizierte QUIC-Verbindungen. Alle schützen diese Strecke. Keines dieser Protokolle verpflichtet den Betreiber dazu, die entschlüsselte Anfrage anschließend zu vergessen.

Auch DNSSEC lässt sich nicht aus dem Schlosssymbol ableiten. RFC 8932 trennt Transportverschlüsselung und DNSSEC ausdrücklich. Validiert der Client nicht selbst, beweist eine authentisierte Verbindung nicht, dass der Resolver die DNS-Daten kryptografisch geprüft hat. Der Client vertraut möglicherweise nur dem gesetzten AD-Bit. Ein TLS-Zertifikat identifiziert den Endpunkt; es ist kein Validierungsprotokoll für die gelieferte DNS-Antwort.

Der zweite Nachweis beschreibt die Verarbeitung. Welcher Validierungsmodus lief? Kam die Antwort aus dem Cache? Hat eine Sicherheitsregel, Ausnahme oder Sperrliste sie verändert? Wurden Verbindungen über IP-Adresse, Sitzungswiederaufnahme, HTTP-Merkmale, TLS-Parameter oder Anfragemuster zusammengeführt? RFC 9076 weist darauf hin, dass selbst verschlüsselte Anfragen auf der Eingangsseite mit unverschlüsselten Anfragen korreliert werden können, die den rekursiven Resolver verlassen.

Ein fest ausgewählter Resolver schafft Klarheit darüber, wer die Fragen in unterschiedlichen Netzen sieht. Derselbe Dienst kann dadurch aber einen Nutzer leichter über Netzwechsel hinweg erkennen. Weniger Beobachter unterwegs und weniger Korrelation am Ziel sind zwei verschiedene Datenschutzziele. Der Erfolg des einen darf nicht als Nachweis für das andere gelten.

Antwortfilter gehören ebenfalls zur Verarbeitung. Nach RFC 8932 soll eine RPS ausweisen, ob Antworten aus Gründen der Netzsicherheit, aufgrund bindender rechtlicher Anordnungen, wegen einer freiwilligen Risikopolitik, aus kommerziellen oder aus anderen Gründen verändert werden. Auch Herkunft und Verwaltung der Listen sollen erkennbar sein. Ein vertraulicher Kanal kann eine gefilterte Antwort liefern. Die Bezeichnung „sicheres DNS“ erklärt nicht, welche der beiden Eigenschaften gemeint ist.

Der dritte Nachweis gilt Speicherung und Zugriff. RFC 8932 empfiehlt, Daten möglichst wenig oder gar nicht aufzubewahren. Wo Speicherung nötig ist, sollen die Daten verschlüsselt sowie nach Möglichkeit aggregiert, pseudonymisiert oder anonymisiert werden. Logfristen sollen auf betriebliche und anwendbare regulatorische Erfordernisse beschränkt bleiben; Zugriff soll nur das Personal erhalten, das ihn für seine Aufgabe benötigt.

Zwischen Richtlinie und Ausführung bleibt ein messbarer Abstand. „Sieben Tage“ ist eine Zusage; ein Löschlauf kann zeigen, dass ein bestimmter Bestand fristgerecht entfernt wurde. Ein Rollenmodell zeigt erlaubte Zugriffe; das Zugriffsprotokoll zeigt tatsächliche. Festplattenverschlüsselung schließt einen Export nicht aus. Auch Pseudonymisierung ist nicht mit Anonymität gleichzusetzen: Ein stabiler Ersatzwert ermöglicht weiterhin Langzeitverknüpfungen und kann bei verfügbarer Zuordnung oder Methode rückführbar sein.

Der vierte Nachweis folgt den Daten aus dem Resolver heraus. Rekursive Auflösung benötigt Anfragen an andere Resolver oder autoritative Server. RFC 8932 empfiehlt QNAME-Minimierung, damit jede Ebene nur den notwendigen Namensteil erhält; RFC 9156 aktualisiert das Verfahren. Der EDNS-Client-Subnet-Parameter soll möglichst nicht verwendet werden. Falls er betrieblich nötig ist, soll der kürzeste praktikable Präfix übermittelt und die tatsächliche Regel offengelegt werden.

Eine unabhängige Messung kann beobachten, dass bei einem Test der Name minimiert und kein ECS gesendet wurde. Das ist guter Nachweis für Zeitpunkt, Messort und Testfall. Es belegt nicht jedes Ziel, jeden Forwarder und jeden Ausnahmezweig. Nachträgliche Weitergabe gespeicherter Daten ist von außen meist überhaupt nicht sichtbar. Ein sauber geschützter erster Abschnitt garantiert keinen sparsamen zweiten.

Deshalb verlangt die RPS mehr als einen allgemeinen Datenschutzhinweis. Sie soll klären, ob IP-Adressen als personenbezogene Daten behandelt werden; welche Informationen erhoben, aufbewahrt, geteilt, verkauft oder vermietet werden; welche Minimierung und Übertragungsbedingungen gelten; welche Ausnahmen, verbundenen Unternehmen und Finanzierungsquellen bestehen; ob DNS-Daten mit anderen Personendaten verknüpft werden; und wie Filter arbeiten. Der Praxisteil ergänzt aktuelle Endpunkte, Authentisierung, Fähigkeiten gegenüber Upstream-Servern, Abweichungen und Support.

Am stärksten ist eine RPS als Wegweiser zu Belegen. QNAME-Minimierung verweist auf Konfiguration und externe Tests. Eine Aufbewahrungsfrist verweist auf Lebenszyklusregeln und Löschergebnisse. Zugangsbeschränkung verweist auf Rollen und auditierte Ereignisse. Weitergabe benennt Empfänger, Zweck, Felder, Bedingung und Ende. Transparenzberichte und unabhängige Prüfungen können weitere Ausschnitte abdecken.

Der Wegweiser ist aber nicht die Ausführung. Audits haben Zeiträume, Stichproben und Ausschlüsse. Messungen haben Standorte. Berichte hängen vom Zugriff der Verfasser ab. Eine veröffentlichte RPS kann einer geänderten Konfiguration hinterherlaufen. Daraus folgt nicht, dass Datenschutz unbeurteilbar wäre. Es folgt, dass jede Behauptung einen passenden Zeugen und eine sichtbare Gültigkeitsgrenze benötigt.

Dickinson und ihre Mitautoren haben für diese oft verborgenen Betreiberentscheidungen eine öffentliche Form geschaffen. Die professionelle Frage endet damit nicht mehr bei „Ist die Leitung verschlüsselt?“. Sie lautet weiter: Wer darf nach Ankunft der Anfrage entscheiden, welcher Nachweis bleibt zurück und wann muss das Versprechen erneut geprüft werden?

Quellen