So funktioniert DNS-Verschlüsselung

Das Domain Name System (DNS) ist das Adressbuch des Internets. Wenn Sie cloudflare.com oder irgendeine andere Website besuchen, fragt Ihr Browser einen DNS-Resolver nach der IP-Adresse der Website. Leider sind diese DNS-Abfragen und die Antworten darauf in der Regel ungeschützt. DNS-Verschlüsselung würde den Nutzern mehr Privatsphäre und Sicherheit verschaffen. In diesem Beitrag sehen wir uns zwei Mechanismen zur DNS-Verschlüsselung an, nämlich DNS over TLS (DoT) und DNS over HTTPS (DoH), und erklären, wie sie funktionieren.

Bei Anwendungen wird in der Regel das DNS verwendet, um einen Domainnamen in eine IP-Adresse aufzulösen. Der Programmierer, der eine Anwendung geschrieben hat, kümmert sich normalerweise nicht selbst darum. Stattdessen schreibt der Programmierer z. B. fetch("https://example.com/news") und erwartet, dass die Umsetzung von „example.com“ in eine IP-Adresse durch eine Softwarebibliothek erledigt wird.

Hinter den Kulissen ist die Softwarebibliothek dafür zuständig, den externen rekursiven DNS-Resolver zu ermitteln und aufzurufen und den von der Anwendung angeforderten Namen mithilfe des DNS-Protokolls aufzulösen (siehe dazu die Abbildung unten). Die Anwendung kann nicht kontrollieren, welcher externe DNS-Resolver ausgewählt wird und ob Datenschutz und Sicherheit in irgendeiner Form gewährleistet sind. Das hängt von der verwendeten Softwarebibliothek und den Betriebssystemrichtlinien des Geräts ab, auf dem die Software ausgeführt wird.

Übersicht über DNS-Abfrage und -Antwort

Das Betriebssystem bekommt die Adresse des Resolvers meist über das Dynamic Host Configuration Protocol (DHCP) vom lokalen Netzwerk mitgeteilt. Bei Heim- und Mobilfunknetzen ist das typischerweise der Resolver des Internetanbieters (ISP). Bei Unternehmensnetzwerken legt meist der Netzwerkadministrator fest, welcher Resolver ausgewählt wird. Auf Wunsch können Nutzer, die ihr Gerät selbst steuern, den Resolver mit einer bestimmten Adresse überschreiben, z. B. der Adresse eines öffentlichen Resolvers wie 8.8.8.8 von Google oder 1.1.1.1 von Cloudflare, aber die meisten werden sich wahrscheinlich nicht diese Mühe machen, wenn sie sich bei einem öffentlichen WLAN-Hotspot in einem Café oder Flughafen anmelden.

Die Wahl des externen Resolvers wirkt sich direkt auf die Endnutzererfahrung aus. Die meisten Nutzer ändern ihre Resolver-Einstellungen nicht und verwenden wahrscheinlich den DNS-Resolver ihres Netzwerkanbieters. Die am deutlichsten zu beobachtenden Eigenschaften sind dabei Geschwindigkeit und Korrektheit der Namensauflösung. Funktionen, die den Datenschutz oder die Sicherheit verbessern, sind möglicherweise nicht sofort sichtbar, tragen aber dazu bei, dass kein Profil von Ihnen erstellt und Ihre Browseraktivitäten nicht gestört werden können. Dies ist in öffentlichen WLANs besonders wichtig, denn hier kann jeder, der sich in der Nähe aufhält, den drahtlosen Netzwerkverkehr auffangen und entschlüsseln.

Seit der Gründung des DNS im Jahr 1987 ist es weitgehend unverschlüsselt. Jeder, der sich zwischen Ihrem Gerät und dem Resolver einklinkt, kann Ihre DNS-Abfragen und -Antworten ausspähen oder sogar ändern. Das schließt alle Personen in Ihrem lokalen WLAN, Ihren Internetanbieter (ISP) und Transitanbieter ein. Dies kann Ihre Privatsphäre beeinträchtigen, denn die von Ihnen besuchten Domainnamen sind dadurch offen erkennbar.

Was kann man sehen? Nun, betrachten Sie einmal dieses von einem Laptop aufgefangene Netzwerkpaket. Das Gerät ist mit einem Heimnetzwerk verbunden:

Folgende Beobachtungen kann man hier machen:

• Der UDP-Quellport ist 53. Das ist die Standardportnummer für unverschlüsseltes DNS. Die UDP-Nutzlast ist daher wahrscheinlich eine DNS-Antwort.

• Dann kann man annehmen, dass die Quell-IP-Adresse 192.168.2.254 ein DNS-Resolver ist und die Ziel-IP 192.168.2.14 der DNS-Client.

• Die UDP-Nutzlast könnte tatsächlich als DNS-Antwort geparst werden und zeigt dann, dass der Nutzer twitter.com besuchen wollte.

• Bei zukünftigen Verbindungen mit 104.244.42.129 oder 104.244.42.1 handelt es sich höchstwahrscheinlich um Traffic, der sich an „twitter.com“ richtet.

• Bei weiterem verschlüsseltem HTTPS-Traffic zu dieser IP, gefolgt von mehr DNS-Abfragen, kann man annehmen, dass ein Webbrowser zusätzliche Ressourcen von dieser Seite geladen hat. So könnte man möglicherweise die Seiten ermitteln, die ein Nutzer während des Besuchs bei twitter.com betrachtet hat.

Da die DNS-Nachrichten nicht geschützt sind, sind weitere Angriffe möglich:

• Abfragen können an einen Resolver weitergeleitet werden, der sie „kapert“ (DNS Hijacking). Im Vereinigten Königreich beispielsweise geben Virgin Media und BT für nicht existierende Domains eine gefälschte Antwort zurück und leiten die Nutzer auf eine Suchseite um. Diese Umleitung ist möglich, weil der Computer bzw. das Smartphone dem DNS-Resolver, den der ISP über seinen Gatewayrouter per DHCP bekanntgibt, blind vertraut.

• Firewalls können unverschlüsselten DNS-Traffic allein aufgrund der Portnummer einfach abfangen, blockieren oder ändern. Die Betrachtung des Klartexts ist allerdings auch kein Patentrezept zum Erreichen von Sichtbarkeitszielen, denn der DNS-Resolver kann umgangen werden.

Durch DNS-Verschlüsselung haben es Unbefugte nicht mehr so leicht, Ihre DNS-Nachrichten anzusehen oder während der Übertragung zu beschädigen. So wie das Web von unverschlüsseltem HTTP auf verschlüsseltes HTTPS umgestellt wurde, gibt es jetzt Upgrades für das DNS-Protokoll, die das DNS verschlüsseln. Erst durch Verschlüsselung des Internets konnten private und sichere Kommunikation und Handel aufblühen. Die Verschlüsselung des DNS wird den Datenschutz für die Nutzer weiter verbessern.

Es gibt zwei standardisierte Mechanismen für die Absicherung des DNS-Transports zwischen Ihnen und dem Resolver, nämlich DNS über TLS (2016) und DNS-Abfragen über HTTPS (2018). Grundlage ist in beiden Fällen die Transport Layer Security (TLS), mit der auch die Kommunikation zwischen Ihnen und einer Website durch HTTPS abgesichert wird. Bei TLS authentifiziert sich der Server (ob Webserver oder DNS-Resolver) mithilfe eines Zertifikats beim Client (Ihrem Gerät). Dadurch wird sichergestellt, dass keine andere Partei die Identität des Servers (des Resolvers) annehmen kann.

Bei DNS über TLS (DoT) wird die ursprüngliche DNS-Nachricht direkt in den sicheren TLS-Kanal eingebettet. Von außen kann man den abgefragten Namen weder feststellen noch ändern. Die vorgesehene Clientanwendung kann TLS entschlüsseln. Das sieht so aus:

Beim Paket-Trace für unverschlüsseltes DNS war klar, dass eine DNS-Anfrage direkt vom Client gesendet werden kann, gefolgt von einer DNS-Antwort vom Resolver. Beim verschlüsselten DoT werden jedoch einige TLS-Handshake-Nachrichten ausgetauscht, bevor verschlüsselte DNS-Nachrichten gesendet werden:

• Der Client sendet ein „Client Hello“ und gibt bekannt, welche TLS-Funktionen er unterstützt.

• Der Server antwortet mit einem „Server Hello“ und beide vereinbaren die TLS-Parameter zur Absicherung der Verbindung. Die Zertifikatsnachricht enthält die Identität des Servers, die Zertifikatsüberprüfungsnachricht eine digitale Signatur, die vom Client mithilfe des Serverzertifikats überprüft werden kann. Der Client überprüft dieses Zertifikat normalerweise anhand der lokalen Liste vertrauenswürdiger Zertifizierungsstellen, aber in der DoT-Spezifikation werden ausdrücklich alternative Vertrauensmechanismen wie Public Key Pinning genannt.

• Sobald der TLS-Handshake sowohl auf Client- als auch auf Serverseite beendet ist, kann der Austausch verschlüsselter Nachrichten beginnen.

• Im Bild oben ist eine DNS-Abfrage und -Antwort dargestellt. In der Praxis bleibt die sichere TLS-Verbindung aber geöffnet und wird für spätere DNS-Abfragen wiederverwendet.

Das Verfahren, unverschlüsselte Protokolle abzusichern, indem man TLS auf einen neuen Port draufsattelt, wurde schon früher angewendet:

• Webtraffic: HTTP (tcp/80) -> HTTPS (tcp/443)

• E-Mails senden: SMTP (tcp/25) -> SMTPS (tcp/465)

• E-Mails empfangen: IMAP (tcp/143) -> IMAPS (tcp/993)

• Jetzt: DNS (tcp/53 oder udp/53) -> DoT (tcp/853)

Ein Problem bei der Einführung eines neuen Ports besteht darin, dass vorhandene Firewalls ihn möglicherweise blockieren. Entweder, weil sie mit einer Whitelist arbeiten, bei der neue Dienste ausdrücklich aktiviert werden müssen, oder weil sie mit einer Sperrliste arbeiten und ein Netzwerkadministrator einen Dienst ausdrücklich blockiert. Wenn die Verfügbarkeit bei der sicheren Option (DoT) nicht so gut ist wie bei der unsicheren Option, könnten Nutzer und Anwendungen versucht sein, wieder zu unverschlüsseltem DNS zurückzukehren. Angreifer könnten dadurch die Möglichkeit haben, Benutzer zu einer unsicheren Version zu zwingen.

Solche Fallback-Angriffe sind nicht nur theoretisch. Es ist schon vorgekommen, dass HTTPS-Websites durch SSL-Stripping auf HTTP herabgestuft wurden, sodass Angreifer Passwörter stehlen oder Konten kapern konnten.

Ein anderer Ansatz namens „DNS Queries over HTTPS“ (DoH, DNS-Abfragen über HTTPS), wurde vor allem für zwei Anwendungsfälle entwickelt:

• Das oben genannte Problem, bei dem zwischengeschaltete Geräte DNS stören, sollte beseitigt werden. Dazu gehört auch das beschriebene Problem mit der Portblockierung.

• Webanwendungen sollten über vorhandene Browser-APIs auf DNS zugreifen können.DoH ist im Wesentlichen HTTPS, der gleiche verschlüsselte Standard, der auch im Web verwendet wird, und benutzt die gleiche Portnummer (tcp/443). Die Webbrowser haben das unsichere HTTP bereits zugunsten von HTTPS für veraltet erklärt. Damit ist HTTPS auch eine ausgezeichnete Wahl für den sicheren Transport von DNS-Nachrichten. Ein Beispiel für eine solche DoH-Anfrage finden Sie hier.

DoH: DNS-Abfrage und -Antwort werden über einen sicheren HTTPS-Stream übertragen

Einige Nutzer waren besorgt, dass der Einsatz von HTTPS aufgrund der möglichen Verwendung von Cookies für Tracking-Zwecke dem Datenschutz gefährden könnte. Die Entwickler des DoH-Protokolls haben verschiedene Datenschutzaspekte berücksichtigt und ausdrücklich von der Verwendung von HTTP-Cookies abgeraten, um Tracking zu verhindern. Diese Empfehlung wird weithin eingehalten. Durch die Sitzungswiederaufnahme bei TLS verbessert sich die Performance des TLS-1.2-Handshakes. Sie kann jedoch möglicherweise zum Korrelieren von TLS-Verbindungen verwendet werden. Glücklicherweise muss bei TLS 1.3 die TLS-Sitzung weniger oft wieder aufgenommen werden, weil standardmäßig weniger Nachrichtenaustausch erforderlich ist. Die damit verbundenen Datenschutzbedenken werden dadurch wirksam entschärft.

Der Einsatz von HTTPS bedeutet, dass DoH auch von Verbesserungen des HTTP-Protokolls profitieren kann. Beispielsweise könnte das HTTP/3-Protokoll, das gerade entwickelt wird und auf QUIC aufbaut, zusätzliche Performance-Verbesserungen bei Paketverlusten wegen fehlender Head-of-Line-Blockierung bieten. Das bedeutet, dass über den sicheren Kanal mehrere DNS-Abfragen gleichzeitig gesendet werden können, ohne sich gegenseitig zu blockieren, wenn ein Paket verloren geht.

Es gibt auch bereits einen Entwurf für DNS über QUIC (DNS/QUIC). Er ähnelt DoT, hat durch QUIC jedoch nicht das Head-of-Line-Blockierungsproblem. Für HTTP/3 und DNS/QUIC muss man jedoch auf einen UDP-Port zugreifen können. Theoretisch kann man in beiden Fällen wieder auf DoH über HTTP/2 bzw. auf DoT zurückgreifen.

DoT und DoH sind noch relativ neu und nicht universell im Einsatz. Auf der Serverseite werden sie von wichtigen öffentlichen Resolvern wie 1.1.1.1 von Cloudflare und Google DNS unterstützt. Viele ISP-Resolver unterstützen sie jedoch noch nicht. Eine kleine Liste öffentlicher Resolver, die DoH unterstützen, finden Sie unter DNS-Serverquellen, eine weitere Liste öffentlicher Resolver, die DoT und DoH unterstützen, finden Sie unter Öffentliche Resolver mit DNS-Datenschutz.

Es gibt zwei Methoden zur Aktivierung von DoT oder DoH auf Endnutzergeräten:

• Man kann die Unterstützung in Anwendungen einbauen und den Resolver-Dienst des Betriebssystems so umgehen.

• Man kann die Unterstützung in das Betriebssystem einbauen und damit auch transparent für Anwendungen zur Verfügung stellen.

Auf der Clientseite gibt es normalerweise drei Konfigurationsmodi für DoT oder DoH:

• Aus: DNS wird nicht verschlüsselt.

• Opportunistischer Modus: Es wird versucht, einen sicheren Transportweg für DNS zu verwenden, man kehrt aber zu unverschlüsseltem DNS zurück, wenn ersteres nicht verfügbar ist. Dieser Modus ist anfällig für Downgrade-Angriffe, bei denen ein Angreifer ein Gerät zwingen kann, unverschlüsseltes DNS zu verwenden. Er soll Datenschutz gewährleisten, solange es keine zwischengeschalteten aktiven Angreifer gibt.

• Strenger Modus: Es wird versucht, einen sicheren Transportweg für DNS zu verwenden. Wenn ein solcher nicht verfügbar ist, wird ein harter Fehler ausgelöst und eine Fehlermeldung für den Nutzer angezeigt.

The current state for system-wide configuration of DNS over a secure transport:

• Android 9: supports DoT through its “Private DNS” feature. Modes:
  • Opportunistic mode (“Automatic”) is used by default. The resolver from network settings (typically DHCP) will be used.
  • Strict mode can be configured by setting an explicit hostname. No IP address is allowed, the hostname is resolved using the default resolver and is also used for validating the certificate. (Relevant source code)
• iOS and Android users can also install the 1.1.1.1 app to enable either DoH or DoT support in strict mode. Internally it uses the VPN programming interfaces to enable interception of unencrypted DNS traffic before it is forwarded over a secure channel.
• Linux with systemd-resolved from systemd 239: DoT through the DNSOverTLS option.
  • Off is the default.
  • Opportunistic mode can be configured, but no certificate validation is performed.
  • Strict mode is available since systemd 243. Any certificate signed by a trusted certificate authority is accepted. However, there is no hostname validation with the GnuTLS backend while the OpenSSL backend expects an IP address.
  • In any case, no Server Name Indication (SNI) is sent. The certificate name is not validated, making a on-path attacker rather trivial.
• Linux, macOS, and Windows can use a DoH client in strict mode. The cloudflared proxy-dns command uses the Cloudflare DNS resolver by default, but users can override it through the proxy-dns-upstream option.

Der aktuelle Stand für die systemweite Konfiguration von DNS über einen sicheren Transportweg:

• Android 9: unterstützt DoT über seine Funktion „Privates DNS“. Modi:

• Der opportunistische Modus („Automatisch“) wird standardmäßig verwendet. Der Resolver aus den Netzwerkeinstellungen (in der Regel DHCP) wird verwendet.

• Der strenge Modus kann durch ausdrückliche Festlegung eines Hostnamens konfiguriert werden. Es ist keine IP-Adresse zulässig, der Hostname wird mit dem Standardresolver aufgelöst und auch zum Überprüfen des Zertifikats verwendet. (Quellcode hierzu)

• iOS- und Android-Nutzer können auch die 1.1.1.1-App installieren und damit DoH- oder DoT-Unterstützung im strikten Modus aktivieren. Intern benutzt sie die VPN-Programmierschnittstellen, um unverschlüsselten DNS-Traffic abfangen zu können, der dann über einen sicheren Kanal weitergeleitet wird.

• Linux mit systemd-resolved ab systemd 239: DoT über die Option DNSOverTLS.

• „Aus“ ist die Standardeinstellung.

• Der opportunistische Modus kann konfiguriert werden, es wird jedoch keine Zertifikatvalidierung durchgeführt.

• Der strenge Modus ist ab systemd 243 verfügbar. Jedes von einer vertrauenswürdigen Zertifizierungsstelle signierte Zertifikat wird akzeptiert. Es gibt jedoch keine Hostnamen-Validierung mit dem GnuTLS-Backend, und das OpenSSL-Backend erwartet eine IP-Adresse.

• In keinem Fall wird eine Server Name Indication (SNI) gesendet. Der Zertifikatsname wird nicht validiert, was Man-in-the-Middle-Angriffe erleichtert.

• Bei Linux, macOS und Windows kann man einen DoH-Client im strengen Modus verwenden. Beim Befehl cloudflared proxy-dns wird standardmäßig der DNS-Resolver von Cloudflare benutzt, aber der Nutzer kann ihn über die Option proxy-dns-upstream überschreiben.

Webbrowser unterstützen DoH statt DoT:

• Firefox 62 unterstützt DoH und bietet mehrere Einstellungen für Trusted Recursive Resolver (TRR) an. Standardmäßig ist DoH deaktiviert, aber Mozilla hat gerade versuchsweise DoH für einige Benutzer in den USA aktiviert. Bei diesem Experiment wird derzeit der 1.1.1.1-Resolver von Cloudflare verwendet, denn wir sind momentan der einzige Anbieter, der die von Mozilla geforderte strenge Resolver-Richtlinie einhält. Da viele DNS-Resolver immer noch keinen verschlüsselten DNS-Transport unterstützen, wird Mozillas Vorgehensweise dazu führen, dass mehr Nutzer durch DoH geschützt werden.

• Wenn die Einstellung im Rahmen des Experiments oder über die Option „DNS über HTTPS aktivieren“ eingeschaltet ist, verwendet Firefox den opportunistischen Modus (network.trr.mode=2 in about:config).

• Der strenge Modus kann mit network.trr.mode=3 aktiviert werden, hierfür muss jedoch ausdrücklich eine Resolver-IP angegeben werden (z. B. network.trr.bootstrapAddress=1.1.1.1).

• Firefox ignoriert zwar den Standard-Resolver des Systems, kann aber mit alternativen Resolvern konfiguriert werden. Bei Enterprise-Bereitstellungen mit einem Resolver, der DoH nicht unterstützt, gibt es außerdem die Option, DoH zu deaktivieren.

• Chrome 78 aktiviert opportunistisches DoH, wenn die Adresse des System-Resolvers mit einem der hartcodierten DoH-Anbieter übereinstimmt (Quellcodeänderung). Dieses Experiment ist für alle Plattformen außer Linux und iOS aktiviert. Enterprise-Bereitstellungen sind standardmäßig ausgenommen.

• Opera 65 verfügt zusätzlich über eine Option, um DoH über den 1.1.1.1-Resolver von Cloudflare zu aktivieren. Diese Funktion ist standardmäßig deaktiviert. Wird sie aktiviert, verwendet sie anscheinend den opportunistischen Modus: Wenn 1.1.1.1:443 (ohne SNI) erreichbar ist, wird dieser Resolver verwendet. Andernfalls wird weiterhin der Standard-Resolver ohne Verschlüsselung benutzt.

Die Seite DNS über HTTPS aus dem curl-Projekt enthält eine umfassende Liste von DoH-Anbietern und zusätzlichen Implementierungen.

Als Alternative zum Verschlüsseln des vollständigen Netzwerkpfads zwischen Gerät und externem DNS-Resolver kann man einen Mittelweg einschlagen und zwischen Geräten und dem Gateway des lokalen Netzwerks unverschlüsseltes DNS verwenden, aber den gesamten DNS-Traffic zwischen Gatewayrouter und externem DNS-Resolver verschlüsseln. Wenn man davon ausgeht, dass das kabelgebundene oder drahtlose Netzwerk sicher ist, würde man so alle Geräte im lokalen Netzwerk vor einer Ausspähung durch den ISP oder andere Widersacher im Internet schützen. Da öffentliche WLAN-Hotspots nicht als sicher angesehen werden können, wäre so etwas in offenen WLANs nicht sicher. Selbst wenn es mit WPA2-PSK passwortgeschützt ist, können andere weiterhin unverschlüsselte DNS-Nachrichten ausspionieren und verändern.

In den vorherigen Abschnitten wurden die sicheren DNS-Transportwege DoH und DoT beschrieben. Mit diesen Maßnahmen kann man aber nur sicherstellen, dass der Client eine unmanipulierte Antwort vom DNS-Resolver erhält. Es schützt den Client nicht davor, dass der Resolver eine falsche Antwort zurückliefert (durch DNS Hijacking oder DNS Cache Poisoning). Die „richtige“ Antwort wird vom Besitzer einer Domain oder Zone bestimmt, wie vom autoritativen Nameserver gemeldet. Mit DNSSEC können Clients die Integrität der zurückgegebenen DNS-Antwort überprüfen und unbefugte Manipulationen auf dem Weg zwischen Client und autoritativem Nameserver abfangen.

Der Einsatz von DNSSEC wird jedoch durch Middleboxes behindert, die DNS-Nachrichten falsch weiterleiten, und selbst wenn die Informationen verfügbar sind, gibt es Stubresolver, die von Anwendungen verwendet werden und die Ergebnisse nicht einmal überprüfen. In einem Bericht aus dem Jahr 2016 wurde festgestellt, dass nur 26 % der Nutzer DNSSEC-validierende Resolver verwenden.

DoH und DoT schützen den Transport zwischen dem Client und dem öffentlichen Resolver. Der öffentliche Resolver muss möglicherweise weitere autoritative Nameserver aufrufen, um einen Namen aufzulösen. Traditionell wird zwischen jedem Resolver und dem autoritativen Nameserver unverschlüsseltes DNS benutzt. Um auch diese DNS-Nachrichten zu schützen, haben wir ein Experiment mit Facebook durchgeführt und DoT zwischen 1.1.1.1 und den autoritativen Nameservern von Facebook eingesetzt. Ein sicherer Kanal mit TLS erhöht zwar die Latenz, das kann sich über viele Abfragen hinweg aber amortisieren.

Durch die Transportverschlüsselung sind Resolver-Ergebnisse und Metadaten geschützt. Die beim EDNS Client Subnet (ECS) in DNS-Abfragen enthaltenen Informationen könnten beispielsweise die ursprüngliche Adresse des Clients offenlegen, der die DNS-Abfrage ausgelöst hat. Wenn diese Informationen unterwegs ausgeblendet werden, verbessert dies den Datenschutz. Außerdem wird verhindert, dass fehlerhafte Middleboxes aufgrund von Problemen bei der DNS-Weiterleitung DNSSEC ausschalten.

Die DNS-Verschlüsselung kann Personen oder Organisationen vor Probleme stellen, die darauf bauen, dass sie den DNS-Traffic selbst überwachen oder ändern können. Sicherheitseinrichtungen, die sich auf passive Überwachung stützen, beobachten den gesamten eingehenden und ausgehenden Netzwerkverkehr auf einem Rechner oder am Rand eines Netzwerks. Wenn die DNS-Abfragen unverschlüsselt sind, könnten sie potenziell Rechner erkennen, die beispielsweise mit Malware infiziert sind. Wenn die DNS-Abfrage verschlüsselt wird, können passive Überwachungslösungen keine Domainnamen überwachen.

Einige Parteien erwarten von einem DNS-Resolver eine Inhaltsfilterung für Zwecke wie:

• Blockieren von Domains, die für die Verbreitung von Malware verwendet werden.

• Blockieren von Werbung.

• Filterung als Kindersicherung und Blockieren von Domains, die mit Inhalten für Erwachsene verknüpft sind.

• Blockieren des Zugriffs auf Domains, die nach örtlichen Gesetzen illegale Inhalte bereitstellen.

• Anbieten eines Split-Horizon-DNS, das je nach Quellnetzwerk unterschiedliche Antworten gibt.

Wenn man den Zugriff auf Domains über den DNS-Resolver blockiert, hat das den Vorteil, dass man es zentral tun kann, ohne es in jeder einzelnen Anwendung neu implementieren zu müssen. Leider ist dies auch eine ziemlich grobe Methode. Angenommen, eine Website hostet Inhalte für mehrere Nutzer auf example.com/videos/for-kids/ und example.com/videos/for-adults/. Der DNS-Resolver sieht nur „example.com“ und kann diese Domain entweder blockieren oder nicht. In diesem Fall wären anwendungsspezifische Steuerelemente wie Browsererweiterungen effektiver, denn sie würden tatsächlich die URLs betrachten und könnten selektiv verhindern, dass auf Inhalte zugegriffen wird.

Die DNS-Überwachung ist kein Allheilmittel. Malware kann das DNS ganz umgehen und IP-Adressen hartkodieren oder alternative Methoden verwenden, um eine IP-Adresse abzufragen. Allerdings ist nicht jede Malware so kompliziert, mit DNS-Überwachung kann man also immer noch eine tiefe Verteidigungslinie aufbauen.

Alle diese Anwendungsfälle für nicht-passive Überwachung oder DNS-Blockierung erfordern Unterstützung des DNS-Resolvers. Bei Bereitstellungen, für die der aktuelle Resolver auf opportunistisches DoH/DoT aktualisiert werden muss, bleibt dieselbe Funktionalität erhalten wie normalerweise über unverschlüsseltes DNS. Leider ist dies anfällig für Downgrades, wie bereits erwähnt. Um dieses Problem zu lösen, kann ein Systemadministrator Endpunkte auf einen DoH/DoT-Resolver im strengen Modus verweisen. Im Idealfall geschieht dies über sichere Geräteverwaltungslösungen (MDM, Gruppenrichtlinien unter Windows usw.).

Einer der Grundpfeiler des Internets ist es, Namen mithilfe des DNS einer Adresse zuzuordnen. Beim DNS werden traditionell unsichere, unverschlüsselte Transportwege verwendet. Dies wurde von ISPs in der Vergangenheit schon für das Einschleusen von Werbung missbraucht, aber es führt auch zu einer Lücke beim Datenschutz. Durch unverschlüsseltes DNS können neugierige Cafébesucher Ihre Aktivitäten verfolgen. Alle diese Problembereiche können durch DNS über TLS (DoT) oder DNS über HTTPS (DoH) gelöst werden. Diese Techniken zum Schutz des Nutzers sind relativ neu und werden zunehmend angenommen.

Aus technischer Sicht sind DoH und HTTPS sehr ähnlich. DoH liegt im allgemeinen Branchentrend, unsichere Lösungen für veraltet zu erklären. DoT ist ein einfacherer Transportmodus als DoH, da die HTTP-Schicht entfernt wird. Dadurch lässt es sich aber auch einfacher blockieren, entweder absichtlich oder versehentlich.

Neben der Nutzung eines sicheren Transportwegs kommt es auf die Wahl des DNS-Resolvers an. Einige Anbieter verwenden den lokal konfigurierten DNS-Resolver, versuchen jedoch, den unverschlüsselten Transport opportunistisch durch einen sichereren Transport (DoT oder DoH) zu ersetzen. Leider wird meist standardmäßig ein vom ISP bereitgestellter DNS-Resolver verwendet, der möglicherweise keine sicheren Transporte unterstützt.

Mozilla hat sich für eine andere Vorgehensweise entschieden. Anstatt sich auf lokale Resolver zu verlassen, die möglicherweise nicht einmal DoH unterstützen, können sie dem Benutzer gestatten, ausdrücklich einen Resolver auszuwählen. Von Mozilla empfohlene Resolver müssen hohen Standards gerecht werden, um die Privatsphäre der Benutzer zu schützen. Damit DNS-basierte Kindersicherungsmethoden funktionsfähig bleiben und um den Split-Horizon-Anwendungsfall zu unterstützen, hat Mozilla einen Mechanismus aufgenommen, durch den private Resolver DoH deaktivieren können.

Die DoT- und DoH-Transportprotokolle sind startklar für mehr Sicherheit im Internet. Wie in früheren Paket-Traces zu sehen, ähneln diese Protokolle den vorhandenen Mechanismen zum Absichern des Anwendungsverkehrs. Wenn diese Sicherheits- und Datenschutzlücke geschlossen ist, müssen wir uns noch mit vielen weiteren befassen.