Wie ODoH und DNSCrypt Ihre Privatsphäre schützen

Netzwerkgeräte senden zur Auflösung von Domainnamen in IP-Adressen laufend DNS-Anfragen ins Internet. Doch damit liegen die Surfgewohnheiten der Nutzer auch für Dritte offen. Jeder, der die DNS-Anfragen und -Antworten im lokalen Netz, in der Firma, beim Provider oder an Internetknoten wie dem DE-CIX mitliest, kann anhand der Quell-IP-Adressen erkennen, welche User welche Webseiten oder Dienste im Internet nutzen. Apple macht sich nun stark, um die DNS-Anfragen gegen unerwünschte Protokollierung abzusichern. Ab dem Herbst sollen Apples iCloud+-Abonnenten diese (und andere Schutzfunktionen) als „Private Relay“ aktivieren können.

Der Plan passt gut zu Apples Aktivitäten rund um den Privatsphärenschutz, denn alle für die Internetkommunikation ausgelegten Geräte müssen das Domain Name System (DNS) befragen, um Verbindungen zu den Zielservern aufbauen zu können. Das DNS übersetzt menschenlesbare Domainnamen wie ct.de in maschinenlesbare IP-Adressen (z. B. 193.99.144.80 und 2a02:2e0:3fe:1001:302::). Die allermeisten Geräte – PCs, Smartphones, Smart-TVs, Router – befragen das DNS aber so wie 1987 spezifiziert, nämlich unverschlüsselt. Darauf antwortet das DNS ebenfalls im Klartext. Deshalb sind DNS-Anfragen und -Antworten für Lauscher und Werbetreibende eine leicht zugängliche Quelle zum Erstellen von Nutzerprofilen. Den Ablauf der DNS-Kommunikation und auch die Stellen, an denen DNS-Daten abgefischt werden, zeigt die Infografik „Übliche DNS-Hierarchie“.

Diese Lücken im Privatsphärenschutz lassen sich nur allmählich stopfen. Der anfälligste Abschnitt der DNS-Kommunikation läuft zwischen dem Client der Benutzer und einem DNS-Resolver ab, den standardmäßig der Internetprovider betreibt. Für die Verschlüsselung zwischen Client und Resolver gibt es etliche Methoden. Die Internet Engineering Task Force (IETF) hat seit 2017 beispielsweise DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) spezifiziert, DNS-over-Quic (DoQ) ist in Arbeit. DNSCrypt ist ein älteres, quelloffenes Verfahren, das eine separate Entwicklergruppe vorantreibt. Ein Beispiel für verschlüsselnde DNS-Clients ist Stubby (siehe ct.de/yzpf), der DNS-Daten gemäß dem Protokoll DoT chiffriert.

Aber mit all diesen Methoden wird die DNS-Kommunikation nur auf der Übertragungsstrecke geschützt, und zwar gegen Mitlesen und gegen Manipulation. Das ist schon ein wichtiger Schritt, aber noch nicht genug, denn der Betreiber des Resolvers kann weiterhin lesen, welche Domainnamen ein Client anfragt. Das verhindern die jüngsten Protokolle im DNS-Bereich, indem sie die IP-Adresse des Clients vor dem Resolver-Betreiber verbergen.

Es gibt bereits zuverlässige Implementierungen, die man ohne besondere Kenntnisse auf macOS, Windows, Linux und anderen Betriebssystemen installieren kann. Mit ein bisschen Tipparbeit im Terminal ist das in weniger als einem Stündchen erledigt. Alle dazu erforderlichen Schritte beschreiben wir ab der Seite 110. Wir empfehlen, vorher diesen Beitrag zu Ende zu lesen, denn um die optimale Konfiguration einzustellen, brauchen Sie ein Grundverständnis von den Zusammenhängen.

Weltweit bieten inzwischen sehr viele Institutionen und Firmen verschlüsselnde DNS-Dienste auf Basis der DoT- und DoH-Protokolle. Die drei größten sind Google, Cloudflare und Quad9. Daneben gibt es Organisationen wie Digitalcourage oder die Schweizer Digitale Gesellschaft, die Privatsphärenschutz zusichern, und auch Provider rüsten ihre DNS-Server auf DoT oder DoH auf. Dazu gehört beispielsweise die Deutsche Telekom, die seit Anfang 2021 DoT und seit Juli auch DoH für beliebige Nutzer innerhalb und außerhalb ihrer Netze anbietet (ct.de/-6139243).

Praktisch alle Resolver-Anbieter versprechen, keine Profile einzelner Nutzer zu erstellen – dazu gehören sogar kommerzielle Anbieter wie Google, deren Geschäft ausdrücklich auf der Verwertung von Nutzerdaten gründet. Das klingt widersprüchlich, denn man erwartet gerade von kostenlosen weltweiten Resolver-Infrastrukturen, dass sie zum Abschöpfen von Nutzerdaten errichtet wurden. Um einen solchen Anschein gar nicht erst zu erwecken, finanziert sich die Non-Profit-Organisation Quad9 allein aus Spenden.

Und Cloudflare versicherte im Gespräch mit c’t, an Metadaten einzelner Anwender gar nicht interessiert zu sein. Stattdessen setze die Firma ihre weltweite DNS-Infrastruktur mehr nebenbei zur Analyse des Gesamtverkehrs ein. So könne Cloudflare anhand von Trends Abwehrstrategien für Großkunden entwickeln. Der Hauptantrieb seien aber kommerzielle Internetsicherheitsdienste, für deren reibungslosen Betrieb ein eigener schneller DNS-Dienst die Grundvoraussetzung sei.

Nur verlagert, nicht verbessert

Die Richtlinien und Geschäftsmodelle klingen zwar durchweg plausibel, aber letztlich ändern die verschlüsselnden DNS-Dienste DoT und DoH nichts am Grundproblem der Anwender: Wenn sie nun vom Resolver des Providers (z. B. Telekom oder Vodafone) auf die von Quad9, Google oder auch Digitalcourage umsteigen, verlagern sie nur den Vertrauenspunkt. Doch kein Anbieter kann wirklich garantieren, dass Metadaten nicht anderweitig verwendet werden, als in den Geschäftsbedingungen oder Richtlinien angegeben – auf staatliche Anordnung hin müssten alle die eingehenden Metadaten der Nutzer sammeln und herausgeben.

Es gibt mehrere Auswege aus diesem Dilemma. Beispielsweise könnte man DNS-Lookups über den Anonymisierungsdienst Tor versenden. Davon raten wir aber ab, denn die Auflösung über Tor läuft nur langsam und unzuverlässig und Betreiber von Tor-Exit-Nodes müssten auf staatliche Anordnung hin Metadaten ebenfalls sammeln und herausgeben.

Einen ganz neuen Ansatz haben Paul Schmitt und Kollegen an der Princeton University schon 2019 vorgestellt. Deren Publikation finden Sie über ct.de/yzpf — so wie alle übrigen Literaturquellen zu diesem Artikel. Die kurze Erklärung: Die Methode von Schmitt und Kollegen verhindert, dass ein Resolver-Betreiber die IP-Adressen seiner Nutzer überhaupt erst erfährt. Sie führt eine zusätzliche Schicht in der DNS-Hierarchie ein, indem sie ein Relay vor den Resolver setzt.

Für die ausführliche Erklärung stellen wir einen Überblick über die aktuelle DNS-Hierarchie und den üblichen Kommunikationsablauf voran: Bisher sind bei einem DNS-Lookup meistens fünf bis sechs Server an der Auflösung einer Zieldomain zur zugehörigen IP-Adresse beteiligt (manchmal deutlich mehr, gelegentlich auch weniger). Jeder davon hat eine spezielle Rolle.

Der Reihe nach sind das der Stub-Resolver beim Client, der Proxy im Router, der rekursive Resolver des Providers oder DNS-Anbieters, der Root-Server (oberste Ebene der DNS-Hierarchie), der TLD-Nameserver (z. B. Nameserver der .de-Domain) und der autoritative Nameserver (der für die Domain zuständige Server), der die IP-Adresse der angefragten Domain kennt und auf Anfrage meldet. Einige TLD-Betreiber können autoritative Daten der Domains vorhalten (das geht zum Beispiel bei der .de-Domain), was die Anzahl der Server unter fünf drückt.

Dreh- und Angelpunkt

Dreh- und Angelpunkt bei DNS-Lookups ist der rekursive Resolver. Er nimmt die DNS-Anfrage des Benutzers entgegen (z. B. ct.de), klappert nacheinander den Root-Server nach der IP-Adresse des TLD-Servers (z. B. 194.246.96.1 für .de), den TLD-Server nach der Adresse des autoritativen Servers (z. B. 213.133.105.6 für robotns2.second-ns.de) und den autoritativen Server nach der IP-Adresse der Zieldomain ab (193.99.144.80 für ct.de) – es sei denn, er hat sie bereits im Cache. Wenn ihm die IP-Adresse der Zieldomain vorliegt, schickt er sie zusammen mit dem Inhalt der Anfrage an den Stub-Resolver zurück, also an den Client des Anwenders, und dessen Browser steuert dann zum Beispiel die IP-Adresse von ct.de an. Der Vorgang ist für IPv6-Adressen gleich, wir haben sie der Übersicht halber weggelassen.

Über den rekursiven Resolver können private Metadaten in zwei Richtungen abfließen: an den Betreiber des rekursiven Resolvers und an die Betreiber der Root-Server und der TLDs. Letzteres passiert, wenn der rekursive Resolver sowohl Root- als auch TLD-DNS-Servern die komplette DNS-Anfrage des Clients schickt. Denn Resolver kommunizieren bisher grundsätzlich unverschlüsselt mit Root- und TLD-DNS-Servern, und daher können auch die Betreiber von .uk und .co.uk mitlesen, wenn ein Nutzer des anfragenden Resolvers beispielsweise die Domain alcoholics-anonymous.co.uk ansteuern möchte. Wer Einblick in den Verkehr vor und hinter dem rekursiven Resolver hat, kann so mit einigem Aufwand auf einzelne Resolver-Nutzer und deren Interessen schließen.

Dagegen hilft die Query-Name-Minimisation, die gewährleistet, dass die Resolver jede der beteiligten Instanzen nur nach dem nächsten Glied in der Kette befragen. Die Methode ist seit wenigen Jahren spezifiziert und gilt als breitflächig eingeführt. Mit folgendem Befehl können Sie prüfen, ob ein Resolver die Minimisation tatsächlich nutzt:

dig +nodnssec +short TXT qnamemintest.internet.nl

Wenn ja, folgt ein: „Hooray - Qname minimisation is enabled on your resolver :)!“ Wenn nicht: Auch dagegen hilft die Methode von Schmitt und Kollegen: Sie bringen gegen den Metadatenabfluss an den rekursiven Resolvern spezielle Relays ins Spiel, die lediglich die Anfragen von Nutzern entgegennehmen und weiterleiten.

Schmitts Clou

Der Clou daran ist, dass bei Nutzern installierte, spezielle Clients ihre DNS-Anfragen so verschlüsseln, dass nur der Resolver sie entschlüsseln kann (siehe auch Infografik auf S. 111). Damit kennt ein Relay zwar die IP-Adresse eines anfragenden Clients, nicht aber den Inhalt der Anfrage. Und der Resolver kennt zwar den Inhalt, nicht aber den Absender der Anfrage. Ob er dann mit oder ohne Qname-Minimisation arbeitet, spielt keine Rolle, weil sich die Inhalte von DNS-Anfragen nicht mit Nutzer-IP-Adressen verknüpfen lassen.

Damit dieser Ansatz tatsächlich die Privatsphäre schützt, müssen Resolver und Relays unter der Kontrolle verschiedener Instanzen stehen, die ihre Daten untereinander nicht austauschen. Schmitt und Mitstreiter haben auch beschrieben, wie die Schlüssel zum Chiffrieren der DNS-Anfragen erzeugt und an Clients verteilt werden und wie der nächstliegende Resolver konfiguriert wird, damit die DNS-Antworten möglichst schnell beim Nutzer eintreffen. Denn von dieser Geschwindigkeit hängt wesentlich ab, wie schnell der Browser Webseiten aufbaut.

Aber die Relay-Technik ist nicht nur für User nützlich, sondern auch für Relay- und Resolver-Betreiber. Denn je weniger Userdaten bei ihnen auflaufen, desto weniger interessant sind sie für Anfragen von Strafverfolgern und Staatsschützern.

Die Idee hat zunächst bei den Entwicklern der Verschlüsselungstechnik DNSCrypt Anklang gefunden. Deren Client DNSCrypt-Proxy setzt die Methode als „Anonymized DNSCrypt“ seit der Version 2.0.29 auf Grundlage des hauseigenen DNSCrypt-Protokolls um.

Später haben Apple, Cloudflare und Fastly das Konzept aufgegriffen und definieren nun in der IETF gemeinsam einen herstellerübergreifenden Standard. Er gründet auf DNS-over-HTTPS und heißt Oblivious DoH, kurz ODoH.

Apple setzt ODoH bereits seit Sommer 2020 in iOS 14 und macOS 11 stillschweigend zum Auflösen der eigenen Domains ein. Aktuell laufen Feldversuche, bevor der kostenpflichtige Dienst in iOS 15 und macOS 12 für sämtliche DNS-Anfragen von iCloud+-Abonnenten freigeschaltet wird. Cloudflare hat je einen ODoH-Client in Go und Rust implementiert und im Dezember 2020 veröffentlicht.

Beliebte DNS-Filter wie AdGuard Home und Pi-hole eignen sich bisher nicht für ODoH. Immerhin kann man Pi-hole mit dem DNSCrypt-Proxy nachrüsten (siehe ct.de/yzpf) und den Proxy dann wie ab Seite 110 beschrieben im Anonymous-Mode betreiben.

Fazit mit Frage

Das ursprüngliche DNS-Konzept genügt heutigen Anforderungen nicht mehr, weil der Privatsphärenschutz fehlt. Aber mehrere Entwicklergruppen haben mit kryptografischen Methoden zumindest die empfindlichste Strecke der DNS-Kommunikation abgesichert. Dabei kann die Nutzerschar sogar zwischen verschiedenen Varianten wählen. Die technisch am weitesten fortgeschrittenen helfen sogar Resolver-Betreibern, die gar kein Interesse an der Erstellung von Userprofilen haben. Der Abschluss ist erreicht, wenn in einigen Jahren auch der Rest der DNS-Kommunikation abgesichert ist.

Übrig bleibt die Frage, was all der Aufwand nützt, wenn der Netzbetreiber einfach den Verkehr mitschneidet und dann Paket für Paket zuzuordnen versucht, wohin von bestimmten Anschlüssen aus gesurft wird. Antworten dazu finden Sie im Beitrag auf Seite 116. (dz@ct.de)

Infos zur DNS-Anonymisierung, Pi-hole-Nachrüstung: ct.de/yzpf