Das mittlerweile über 30 Jahre alte Domain Name System (DNS) ist nach wie vor einer der wichtigsten Dienste in vielen IP-basierten Netzwerken. Die Hauptaufgabe von DNS ist die Namensauflösung, d.h. die Umsetzung von Domainnamen in IP-Adressen. Große Probleme bei DNS sind die fehlende Sicherheit und Privatsphäre. Die DNS-Kommunikation findet über UDP-Port 53 im Klartext statt und kann daher quasi von jedem mitgelesen und manipuliert werden. Die Missbrauchsmöglichkeiten von DNS sind erschreckend einfach umzusetzen, was viele Fälle in der Vergangenheit zeigen. Darüber hinaus können Nachrichtendienste, Provider und Betreiber von DNS-Servern die DNS-Kommunikation mitlesen und wissen, wer wann welche Internetadressen bzw. -dienste aufgerufen hat. Damit lassen sich Nutzerprofile erstellen und eine großflächige Überwachung realisieren. Einige Anbieter von DNS-Servern nutzen die Daten unter anderem auch für Werbezwecke.
Spätestens jetzt sollte jedem klar sein, dass die ursprüngliche Implementierung von DNS deutliche Nachbesserungen in den Bereichen Privatsphäre, Datenschutz und Sicherheit benötigt.
DNSSEC
Diese Probleme wurden schon früher erkannt. Einige wollte man bereits im Jahr 1999 mittels DNSSEC (Domain Name System Security Extensions) angehen. Die erste Implementierung (RFC 2535) erwies sich jedoch als nicht praxistauglich, weshalb 2005 eine Neufassung von DNSSEC veröffentlicht wurde (RFC 4033). Damit wird DNS um Sicherheitsmechanismen zur Gewährleistung der Authentizität und Integrität der Daten erweitert. Konkret bedeutet dies, dass Zonen signiert werden und DNSSEC-Nutzer somit die Echtheit einer DNS-Anfrage verifizieren können. Wenn die Signatur ungültig ist, werden die Daten verworfen. Auf den Root-Nameservern wurde DNSSEC im Mai 2010 eingeführt.
Allerdings hat sich DNSSEC immer noch nicht flächendeckend durchgesetzt. Die Hauptgründe liegen an der als kompliziert geltenden Umsetzung (ein Relikt aus den Anfangszeiten) und daran, dass nicht alle Probleme von DNS gelöst werden. Beispielsweise werden nach wie vor alle Daten unverschlüsselt übertragen und können mitgelesen und archiviert werden. Des Weiteren werden die Manipulationsmöglichkeiten nicht vollständig unterbunden und einige Provider unterstützen noch immer kein DNSSEC auf ihren DNS-Resolvern. Bei Interesse kann diese Information auf https://internet.nl über den Punkt “Test your connection” geprüft werden. Unabhängig davon bleibt die “letzte Meile” dennoch in fast allen Fällen ungesichert. Ein Großteil der Heimrouter und so gut wie alle Betriebssysteme und Browser unterstützen kein DNSSEC. Damit kann der User nach wie vor nicht darauf vertrauen, dass die DNS-Antworten korrekt sind.
Bei DNSSEC sind die Daten zumindest digital signiert. Die Übertragung erfolgt jedoch im Klartext. Zwischen User und Provider-DNS-Server sind die Daten fast immer komplett ungesichert.
Daraufhin wurden in den letzten Jahren mehrere Protokolle mit dem Ziel entwickelt, die fehlende Privatsphäre und den nicht vorhandenen Datenschutz nachzurüsten. Dies geschieht mittels Verschlüsselung. Mittlerweile haben sich zwei Favoriten durchgesetzt: DNS-Anfragen werden entweder mit TLS verschlüsselt (DNS over TLS (DoT) ) oder in HTTPS verpackt (DNS over HTTPS (DoH)). Anderen Alternativen wie DNSCurve oder DNSCrypt sind faktisch tot.
DNS over TLS (DoT)
Das Prinzip von DoT (RFC 7858 und RFC 8310) ist simpel. Die DNS-Informationen werden über eine TCP-Verbindung mit dem Resolver ausgetauscht, die via Transport Layer Security (TLS) authentifiziert und verschlüsselt ist. Damit können Nutzer die gewünschten Daten vom Nameserver beziehen, ohne dass Dritte mitlesen können. Eine Validierung der DNS-Daten erfolgt nicht durch DoT, deshalb sollte DoT immer in Kombination mit DNSSEC verwendet werden.
Schauen wir uns DNS over TLS genauer an. Die Kommunikation läuft über den TCP-Port 853. Sollte dies nicht funktionieren, ist in der Regel das “normale” DNS via UDP-Port 53 als Fallback aktiv. Dies ist aber von den Sicherheitseinstellungen des Systems abhängig. In der Praxis dürfte dies vor allem in Unternehmen und öffentlichen WLAN-Hotspots problematisch sein, da der relativ unbekannte TCP-Port 853 hier vermutlich blockiert wird. Mit dem Zurückfallen auf UDP-Port 53 ist DoT nutzlos, ohne Fallback funktioniert die Namensauflösung auf dem Client nicht mehr. Ein weiteres Problem ist der relativ große Overhead durch TCP und TLS, der eine Namensauflösung deutlich einbremst. Dies ist allerdings nicht so tragisch, da zum einen geöffnete DoT-Verbindungen für mehrere DNS-Abfragen verwendet werden und zum anderen einige Performance-Optimierungen mit der neuen TLS-Version 1.3 auf den Weg gebracht wurden.
DoT kann ohne Probleme bereits heute genutzt werden. Bei den Betriebssystemen wird das Protokoll ab Android 9 (Pie) unterstützt (siehe Screenshot). Zu finden ist die Option in den Einstellungen unter “Netzwerk & Internet” unter dem Punkt “Privates DNS”. Bei der Option “Automatisch” testet Android, ob der Nameserver DoT anbietet und verwendet es gegebenenfalls. Darüber hinaus kann ab Version 239 des DNS-Resolvers in Linux-Systemd (systemd-resolved) DoT genutzt werden, welches allerdings standardmäßig deaktiviert ist.
Ebenso existieren bereits eine Vielzahl an DNS-Resolvern. Eine gute Übersicht bekannter DoT-Server findet ihr hier beim DNS Privacy Project.
Wenn ihr eure Surf-Gewohnheiten nicht mit großen amerikanischen Konzernen teilen wollt (Google, Cloudflare, usw.), existiert hier eine zweite Liste mit kleineren DoT-Servern und „no logging“-Policy. Einige davon stehen in Deutschland und bieten zusätzlich eine Blockierung von Werbung und Trackern. Empfehlen kann ich euch das Projekt Blahdns.
DNS over HTTPS (DoH)
Auf den ersten Blick scheint DoH (RFC 8484) eine gewisse Ähnlichkeit mit DoT zu haben. Auch hier kommt eine TCP-Verbindung mit TLS zum Einsatz, um Lauscher das Leben schwer zu machen. Der Unterschied ist, dass die DNS-Informationen zusätzlich im HTTPS-Protokoll verpackt sind. Wie bei DoT erfolgt bei DoH keine Validierung der DNS-Daten, weshalb DNSSEC auch hier in Kombination verwendet werden sollte.
DoH wurde in nur wenigen Monaten durch die IETF-Gremien gepeitscht. Als treibende Kräfte hinter DoH stecken unter anderem Mozilla und Google. Kein Wunder, denn DoH ist im Vergleich zu herkömmliches DNS und DoT (beide auf Systemebene) auf Anwendungsebene umgesetzt und steckt damit direkt im Browser. Die DNS-Kommunikation erfolgt via HTTPS zwischen Browser und Webserver. Stichwort HTTPS: Was zunächst als nebensächlich erscheint, könnte in der Praxis gravierende Auswirkungen haben und die bewährte Infrastruktur großflächig umkrempeln.
Theoretisch könnte bei DoH jeder Webserver als DNS-Resolver fungieren. Die ursprüngliche Idee dahinter ist, dass ein Webserver direkt alle für den Webseitenaufbau benötigten IP-Adressen mitliefert und nicht wie bisher, diverse einzelne DNS-Anfragen gestellt werden müssen. Selbst bei komplexen Webseiten wäre nur noch eine einzige DNS-Anfrage notwendig. Allerdings würde dieses Verhalten Tür und Tor für Malware und Phisher öffnen. Webseiten können dir ohne Probleme Antworten für Dritte unterschieben, Stichwort Out-Of-Bailiwick.
Eine weitere Konsequenz ist, dass über DoH-fähige Webserver beliebige DNS-Daten angefragt werden können. Dieser Traffic lässt sich von normalem Web-Traffic nicht mehr unterscheiden und lässt sich im Gegensatz zu DoT praktisch nicht blockieren. Des Weiteren wäre damit auch die Gefahr einer DNS-basierten Zensur gebannt. Wenn jeder Webserver DNS-Daten liefern kann, wäre eine Zensur schlicht und ergreifend aussichtslos. Gleichzeitig könnte die Namensauflösung via DoH dezentral über viele Webserver erfolgen, was automatisch die Privatsphäre stärkt.
Die zuletzt genannten Punkte sind aktuell aber eher Wunschdenken. Die Realität sieht so aus, dass Mozilla und Google in ihren Browsern zwar DoH implementiert haben, die Namensauflösung aber über einen zentralen Server erfolgt. Anstatt einem unabhängigen dezentralen DNS-Verkehr haben wir Stand heute eine ungesunde Zentralisierung bei amerikanischen Großkonzernen, die dann sämtliche Webseiten sehen würden, welche im Browser aufgerufen werden. Was das für die Privatsphäre bedeutet, könnt ihr euch selber ausmalen. Davon abgesehen wären diese zentralen DNS-Knoten dann geradezu prädestiniert für einen staatlichen Lauschangriff.
Ein weiteres Problem könnte sich in größeren Unternehmen ergeben. Mit DoH werden die internen DNS-Resolver umgangen und interne Dienste könnten somit nicht mehr erreichbar sein. Auch die Administrierbarkeit und Fehlersuche gestaltet sich deutlich schwieriger bis unmöglich, wenn zukünftig in jeder Anwendung unterschiedliche DNS-Resolver zum Einsatz kommen.
Eine Liste von verfügbaren DNS-Servern findet ihr beim DNS Privacy Project oder hier bei Github.
Fazit
Zusammengefasst muss ich sagen, dass der Hype um DoT und DoH nicht ganz gerechtfertigt ist. Beide Protokolle verfügen über gewisse Nachteile und sind nicht uneingeschränkt zu empfehlen. Jedem sollte bewusst sein, dass die Absicherung der “letzten Meile” ohne DNSSEC sinnlos ist. DoT und DoH sichern die Verbindung zum DNS-Resolver ab. DNSSEC kümmert sich um die Validierung der erhaltenen DNS-Daten.
Was bedeutet dies nun in der Praxis? Wie so oft wird es keine Lösung geben, die alle problematischen Punkte komplett beseitigt. Ich unterstütze allerdings die Meinung, dass herkömmliches DNS durch seine Dezentralität prinzipiell besser dazu geeignet ist, die Privatsphäre zu schützen. Zentrale DoT- bzw. DoH-Server in den Händen großer Unternehmen bewirken eher das Gegenteil.
Ein möglicher Ansatz wäre die Verwendung eines DNS-Resolvers mit DNSSEC-Unterstützung und eine lokale Kopie der Root-Zone. Diese Anforderungen lassen sich zum Beispiel mit einem Raspberry Pi und Unbound als DNS-Resolver in Kombination mit Hyperlocal umsetzen. Nachteil ist die fehlende Verschlüsselung, was jedoch verschmerzbar ist, da durch Caching und Zonentransfer DNS-Anfragen in vielen Fällen erst gar nicht gestellt werden. Wenn sich ein Lauscher im lokalen Netz bzw. innerhalb der “letzten Meile” befindet, ist DNS vermutlich eines der kleineren Probleme.
Ein anderer Ansatz wäre DNSSEC in Kombination mit DoT. Dabei sollten allerdings möglichst viele DNS-Resolver verwendet werden, sodass die Anfragen auf verschiedene DoT-Server verteilt werden. Damit wird das Erstellen von Profilen erschwert und man könnte sogar die Nutzung von Google, Cloudflare und Co in Erwägung ziehen.
Neueste Kommentare