© Tithi Luadthong, 123RF.com

Einerseits bietet DNS-Verschlüsselung Nutzern in öffentlichen WLANs einen guten Schutz, etwa in Hotels oder in der Bahn. An Universitäten, bei Behörden oder in Unternehmen schadet sie jedoch mehr, als sie nutzt, weil sie das Auswerten und Filtern der Namensauflösung verhindert.

Zu den fundamentalen Diensten im Internet zählt der Dynamic Name Service oder kurz DNS. Sobald ein Anwender einen Rechnernamen zum Beispiel http://www.dfn.de eintippt, findet DNS die zugehörige IP-Adresse, hier 194.15.165.104. Ohne DNS müsste man die IP-Adressen auswendig wissen und direkt in der Adresszeile des Webbrowsers angeben.

Die DNS-Datenpakete laufen unverschlüsselt und nicht signiert durchs Netz. Lediglich eine 16-Bit-Zufallszahl, die eigentlich die Zuordnung von Anfrage und Antwort sicherstellen soll, liefert einen rudimentären Schutz. Der anfragende Client akzeptiert die erste eingehende Antwort mit der richtigen Zufallszahl und speichert sie vorübergehend im Cache. Ein Angreifer muss also nur schneller antworten als der offizielle DNS-Server, um die Anfrage umzubiegen. Gelangen gefälschte DNS-Einträge in den Cache, spricht man vom DNS Cache Poisoning.

Weil der komplette DNS-Verkehr unverschlüsselt bleibt, lässt er sich überwachen und auswerten – unter anderem durch den Provider oder auch den Arbeitgeber. Das kann durchaus gewollt und vorteilhaft sein, etwa wenn der Admin auf diesem Weg unbeabsichtigte Zugriffe auf Server blockiert, die Schadsoftware verteilen.

Zur DNS-Sicherheit

Mit DNSSEC [1] gibt es einen etablierten, aber noch nicht weit genug verbreiteten Standard, um signierte und damit verifizierbare DNS-Antworten zu generieren. Es wäre dringend erforderlich, dass Provider und Organisationen mindestens diesen Standard verwenden, um Angriffe wie DNS Spoofing und DNS Cache Poisoning zu vereiteln. Momentan scheint aber die Sorge zu überwiegen, dass der Einsatz DNS fehleranfälliger macht. Viele große Anwender verzichten deshalb derzeit noch auf DNSSEC.

DNSSEC unterlässt das Verschlüsseln der Inhaltsdaten (Vertraulichkeit) und signiert lediglich die Daten (Integrität). Im Wesentlichen benötigt man pro Domain zwei Schlüssel: einen zum Signieren der Domain-Daten (mit dem Code 256 gekennzeichnet; typisch 1024 Bit) und einen zweiten zum Signieren der Schlüssel (Code 257; typisch 2048 Bit). Die Schlüssel lassen sich per »dig Domain DNSKEY« anzeigen (Listing 1). Bei manchen Versionen von Dig funktioniert auch die umgekehrte Parameterreihenfolge. Um einen problemlosen Schlüsselwechsel zu ermöglichen, dürfen auch alte und neue Schlüssel gleichzeitig eingetragen sein.

;; ANSWER SECTION:
mozilla.org.            6074    IN      DNSKEY  257 3 7
Av//szWRDSGz3g4JkiuQqws79YZ6nwxk0f9PF9MCQSYrRGd0f4Vuuouf
aKdeFvdeY4x9tGmh7FQ51Qi6EEr9LLy2Q8qTtEuN2fJ4PnWBNRfKwhWb
SNQWvq1jwhsXlsAelLz7tO5kptI7TO16p2ncpnhJqfzT5mWJ4nK76YPZ
lu+MZlIYJOMv/OQWD2nVmsjXeO0dnsrL8MyC5wdyPy2gbksWBscsbwN2
34APEYO48B6sovy2fuTVWnj7LDsEh3NzrhjGYlhWmtvrXg3mlFelz/MZ
XrK6uAlp6206Hc669ylfhIcD9d7w0rc9Ms1DFCh5wzVRbnJJF51mW2nC
mh5C8E7xSw==
mozilla.org.            6074    IN      DNSKEY  256 3 7
AwEAAcY1VDPtMAXJPEwna184sRuU6QGYWnccTAyJhpzYQ+AsfK8eZVYS
iA2g8G24ZIvMrzOp6KQdx0XET6/QIO5xD7B0QH9YNXatVsXtzce+9Q9X
klmc78oKRKrVw969aEX91kjRXf6pjRXckJxXdXetxzuL6/E4bMKjQCGX
yJI20TGx

Das Bestätigen der Schlüssel folgt einer Hierarchie: Die DNS-Root-Server haben seit 2010 Unterstützung für DNSSEC und entsprechende Schlüssel hinterlegt. Mit diesen signieren sie dann die Schlüssel, die der Signatur von Schlüsseln der Top-Level-Domains dienen. Mit dem Schlüssel der Top-Level-Domain ».de« wiederum werden dann die Schlüssel der weiteren Domains signiert, zum Beispiel von »mpg.de«. Diese Hierarchie lässt sich mit Tools wie DNSViz [2] einfach visualisieren (Abbildung 1).

Abbildung 1: Die Visualisierung des Schlüsselbaums für die Adresse http://www.mozilla.org mit dem Online-Service DNSViz.

Mit dem Befehl aus Listing 2 lässt sich die Signatur in der DNS-Antwort (»RRSIG«) mit anzeigen (Abbildung 2). Eine manuelle Verifikation klappt nur in einem mehrstufigen aufwendigen Prozess. Der Anwender sollte hier einen DNSSEC-fähigen Resolver einsetzen (siehe Kasten “DNSSEC-Resolver Pi-hole”).

$ dig mozilla.org +dnssec +noall +answer +multi

Abbildung 2: Die Signatur der DNS-Antwort wird im Feld »RRSIG« übertragen.

Abbildung 3: Das Query-Log zeigt in der Weboberfläche, ob DNSSEC zum Einsatz kommt (»SECURE«) oder nicht (»INSECURE«). Eine fehlerhafte Signatur würde an der Stelle mit »BOGUS« markiert werden.

Abbildung 4: Unter Windows prüft der Admin mit Nslookup und einer Testadresse, ob DNSSEC zum Einsatz kommt. Falls nicht, liefert die Anfrage für http://sigfail.verteiltesysteme.net eine IP-Adresse, da die fehlerhafte Signatur nicht geprüft wird.

Prinzipiell kann der Mechanismus zum Verteilen von Schlüsseln für DNSSEC auch Schlüssel für beliebige andere Anwendungen verteilen, etwa für TLS, IPsec, E-Mail-Verschlüsselung und so weiter. Dafür gibt es bei der Schlüsselübertragung ein gesondertes Protokollfeld.

Privatsphäre

Die Vertraulichkeit der DNS-Anfragen lässt sich nur wahren, indem man den DNS-Verkehr verschlüsselt. Eine Lösung dafür bietet DNSCrypt [3], das unmodifizierte DNS-Pakete verschlüsselt über Port 443 austauscht, dabei aber nicht das Protokoll HTTPS verwendet. Es gibt zahlreiche DNS-Anbieter, die DNSCrypt unterstützen.

Eine andere Möglichkeit ist DNS-over-TLS (DoT [4]). Es wickelt den DNS-Verkehr über eine TLS-verschlüsselte Verbindung über Port 853 ab. Zu den Protagonisten dieses Protokolls zählt Google. Android unterstützt DoT ab Version 9 “Pie” ohne Zusatzsoftware. Als öffentliche DNS-Server für dieses Protokoll bieten sich unter anderem Google, Cloudflare, Quad9 und Digitalcourage an. Die Zuordnung zu Port 853 eröffnet übrigens eine einfache Möglichkeit, DoT durch eine Firewall zu blockieren.

Eine weitere Lösung zum besseren Schutz der Privatsphäre der DNS-Nutzer, um die es momentan heftige Diskussionen gibt, ist DNS-over-HTTPS (DoH [5]). Seit Version 62 versteht sich Mozilla Firefox auf dieses Verfahren. Der Anwender muss die Funktion aber (noch?) explizit aktivieren. Darüber hinaus gibt es einige Softwarepakete, die die komplette DNS-Auflösung des Betriebssystems über DoH umleiten. Das Problem dabei: Es kommt nicht mehr der eigene, lokale DNS-Server zum Einsatz, sondern der eines großen Providers wie Cloudflare, Google oder Quad9.

Der Vollständigkeit halber sei auch noch das von Daniel J. Bernstein vorgeschlagene DNSCurve [6] erwähnt, das aber keine große Rolle spielt.

Nachdem die aktuelle Laborversion für die Fritzbox-Modelle 7490 und 7590 DNS-über-TLS (DoT [7]) als neue Funktion unterstützt und auch die kleinen Router von GL-iNet [8] DoT und sogar DNScrypt supporten, dürften sich diese Varianten im Home-Bereich verbreiten.

Nebenwirkungen

Bis jetzt war DNS ein Dienst, der im Betriebssystem konfiguriert und von allen Anwendungen genutzt wurde. Mit den Bestrebungen der Hersteller von Webbrowsern (Chrome, Firefox) und E-Mail-Clients (Thunderbird), DNS zu verschlüsseln, wandert die Namensauflösung aber in die Anwendung, wo sie deren Nutzer statt des Admins einrichtet.

In den meisten Fällen lässt sich der DNS-Server via DHCP für das Betriebssystem konfigurieren. Für Geräte, über die er keine Kontrolle hat (“Bring your own device”, BYOD), kann der Admin externe DNS-Server in der Firewall blockieren, sodass auch diese Clients den lokalen DNS-Server nutzen müssen. So lassen sich dann auch in diesen Fällen Inhaltsfilter (Blockade von Schadsoftware) und DNS-Server für interne Ressourcen (Split Horizon) realisieren.

Kommt aber verschlüsseltes DNS ins Spiel, fällt jede Möglichkeit flach, unerwünschte Inhalte zu blocken oder den DNS-Verkehr auf Domains zu untersuchen, die Malware verteilen. Das liegt nicht immer im Interesse einer Firma, Hochschule, Forschungseinrichtung, Behörde oder dergleichen.

Ein weiteres Problem für die Nutzer ergibt sich zudem, wenn das DNS im Modus Split Horizon laufen soll: Dann behandelt der DNS-Server Anfragen unterschiedlich, je nachdem, ob sie von innerhalb oder außerhalb des lokalen Netzes kommen. Da aber sowohl DoH als auch DoT immer einen externen DNS-Server befragen, würde auch ein Nutzer im internen Netz seiner Einrichtung immer die externe DNS-Antwort erhalten. Damit wären dann Intranet-Seiten nicht mehr erreichbar, wenn ihre Namen innerhalb des lokalen Netzes auf eine andere Adresse verweisen als außerhalb.

Es stellt hingegen kein Problem dar, wenn es Domain-Namen gibt, die nur der interne DNS-Server kennt. Mit den Voreinstellungen lässt sich bewirken, dass Clients den internen DNS-Server über den klassischen DNS-Mechanismus befragen, wenn der DoH-Request keine Antwort liefert. Ein versierter Nutzer könnte jedoch die Konfiguration so ändern, dass sein Gerät den internen DNS-Server nie befragt. Aus der Anwendung heraus, die DoH verwendet, wären für ihn dann einrichtungsinterne Server nicht mehr erreichbar.

Während Schutzmaßnahmen wie DoH und DoT in öffentlichen Netzen (etwa beim WLAN im Hotel oder im ICE) durchaus Sinn ergeben, muss sich eine Hochschule, Forschungseinrichtung oder Behörde gut überlegen, ob sie das will. Derzeit unterstützen Firefox (seit Version 62) und Thunderbird (ab Version 60) DoH. Die Aktivierung erfolgt in den Einstellungen durch den Nutzer (Abbildung 5).

Abbildung 5: So sehen die Einstellungen zum Aktivieren von DoH in Firefox 70 aus.

Android unterstützt DoT seit der Version 9 “Pie”. Der Anwender aktiviert es unter Einstellungen | Netzwerk & Internet über die Option Privates DNS, die Voreinstellung lautet Automatisch. Das bedeutet, dass Android DoT nutzt, wenn es geht, ansonsten nicht.

Google Chrome

Google Chrome offeriert DoH seit der Version 78 (Februar 2018) als experimentelle Option. Das Feature lässt sich in der grafischen Oberfläche leicht aktivieren  [9]. Der Webbrowser kontaktiert dabei denjenigen DNS-Anbieter über DoH, der als klassischer DNS-Provider im Betriebssystem konfiguriert ist.

Dazu ruft der Anwender »chrome://flags« auf und aktiviert Secure DNS lookups (Abbildung 6). Sobald im Betriebssystem einer der unterstützen DNS-Server konfiguriert ist – aktuell die Anbieter Cleanbrowsing, Cloudflare, Comcast, DNS.SB, Google, OpenDNS und Quad9 [10] –, wird DoH aktiviert [11].

Abbildung 6: Der Anwender muss DoH in den experimentellen Funktionen unter »chrome://flags« aktivieren.

Das lässt sich leicht überprüfen. Trotz aktivierter DoH-Option kommt das Protokoll nicht zum Zug, wenn das Betriebssystem den lokalen DNS-Server (etwa der Universität oder Forschungseinrichtung) vorgibt. Konfiguriert man in den Netzwerkeinstellungen jedoch einen der unterstützen DNS-Server (im Beispiel aus Abbildung 7 Cloudflare, also 1.1.1.1), nutzt der Browser DoH.

Abbildung 7: Ist ein unterstützter DNS-Server im Betriebssystem aktiv, nutzt Google Chrome in der Folge DoH.

Sobald ein Chrome-Nutzer die DNS-Server im Betriebssystem konfigurieren kann, vermag er auf diesem Weg auch DoH zu aktivieren. Die einzige Gegenmaßnahme bietet das Blockieren des Ports 53 (DNS) für alle internen Rechner mit Ausnahme des lokalen DNS-Servers. In den Policies sollte der Admin deshalb den Wert »BuiltInDnsClientEnabled« auf »False« setzen [12]: Dann nutzt Chrome DoH nicht, wie Tests des Autors ergaben.

Mozilla Firefox

Mozilla Firefox ermöglicht es einem Netzwerk zu signalisieren, dass DoH nicht erwünscht ist. Dazu fragt der Webbrowser die Domain http://use-application-dns.net über den DNS-Mechanismus des Betriebssystems ab. Antwortet der Server mit »NXDOMAIN« oder »SERVFAIL«, deaktiviert Firefox DoH.

Außerdem sucht der Browser nach Mechanismen wie Google oder Youtube Safe Search sowie Kinderschutzfiltern, die den DNS-Verkehr auswerten, und deaktiviert DoH, wenn er solche Software findet. Dabei handelt es sich allerdings um ein undokumentiertes Feature, das sich wahrscheinlich vor allem an in den USA gebräuchlichen Kinderschutzsystemen orientiert. Außerdem erfolgt die Deaktivierung nur bei per Vorgabe aktivem DoH – das ist derzeit ebenfalls nur in den USA der Fall. Aktiviert dagegen ein Benutzer DoH, dann geht dessen Einstellung grundsätzlich vor [13].

Selbst wenn Firefox TLS 1.3 für die DoH-Verbindung nutzt, sieht man beim Aufbau der HTTPS-Verbindung den Namen des DNS-Servers im SNI-Header (Vorgabe: http://mozilla.cloudflare-dns.com, Abbildung 8). Die Server Name Indication (SNI) dient dazu, dem Server mitzuteilen, mit welchen der gehosteten Server man kommunizieren möchte: Nur so kann der Webserver das zur Webseite passende Zertifikat auswählen.

Abbildung 8: Der DNS-Servername bleibt sichtbar, auch wenn der Verkehr verschlüsselt ist.

Der Standard zur Verschlüsselung des SNI-Headers (Encrypted SNI, ESNI [14]) kommt derzeit bei DoH-Anfragen nicht zum Einsatz, da der Schlüssel für ESNI über DoH ausgetauscht werden muss – ein Henne-Ei-Problem. Damit lässt sich der Default-DoH-Anbieter in Mozilla Firefox sperren, indem man im DNS-Server die DNS-Anfrage zu http://mozilla.cloudflare-dns.com filtert.

Lösungsansätze

Wenn ein Unternehmen die Nutzung der alternativen DNS-Varianten unterbinden möchte, blockiert es DoT einfach in der Firewall, indem es Port 853 für ausgehenden Verkehr sperrt. DNSCrypt und DoH lassen sich via Firewall nur durch inhaltliche Analysen blockieren, da sie Port 443 (HTTPS) nutzen.

Im Internet finden sich Listen der Domain-Namen der Diensteanbieter, bei denen DNSCrypt, DoT oder DoH zu finden ist [15]. Die Anzahl der Server steigt aber stetig an, weshalb es keine dauerhafte Lösung darstellt, den Zugriff auf die momentan gelisteten Ressourcen zu verbieten. Offeriert ein Server unter einer IP-Adresse sowohl DoH als auch eine oder mehrere Websites, bietet das Blockieren der IP-Adresse in der Firewall auch keine gute Lösung.

Besser ist es, über die Datei »policies.json« im Verzeichnis »distribution/« die Einstellungen zum DNS in Firefox und Chrome zu sperren. Unter Windows gelingt das mit einer Group Policy, die auch die portable Version von Firefox beachtet.

Künftig werden aber weitere Programme oder Betriebssysteme verschlüsseltes DNS unterstützen – eine grundsätzliche Lösung muss her. Der Standard ETS (Enterprise Transport Security) der ETSI [16] eignet sich dazu nicht (CVE-2019-9191), da er darauf abzielt, die komplette Kommunikation mitzulesen. Bei BYOD und auch im Education Roaming lassen sich Group Policies nicht einsetzen, da man keinen Zugriff auf die Einstellungen der Rechner und Smart Devices hat.

Es muss auf Dauer eine einheitliche Möglichkeit geben, wie sich in Enterprise-Umgebungen verschlüsselte DNS-Anfragen über die entsprechende Infrastruktur des Unternehmens leiten lassen. Das Blockieren der externen DoH- und DNSCrypt-Provider (beide nutzen Port 443) in der Firewall wird ein Hase-und-Igel-Spiel bleiben und bietet deshalb auch keine Lösung. Moderne Firewalls mit Deep Packet Inspection könnten sicherlich die Protokolle erkennen, blockieren und so die Nutzung des klassischen DNS erzwingen.

Ideal wäre eine Lösung, die in offenen Netzen DoH nutzt, in kontrollierten Umgebungen jedoch die DNS-Infrastruktur der jeweiligen Einrichtung bevorzugt. Dabei lässt sich zur Kommunikation zwischen Clients und DNS-Server durchaus ein verschlüsseltes DNS-Protokoll einsetzen.

Fazit

Es stellt sich die Frage, was der Privatsphäre der Nutzer mehr dient: wenn der Arbeitgeber/Provider die DNS-Anfragen sehen kann, oder wenn einer der großen Internet-Konzerne sie sieht und wahrscheinlich auswertet? Sollen wir den DNS-Dienst auf wenige große Unternehmen konzentrieren? Wie gehen wir mit internen DNS-Servern um?

Die Kombination von DoH/DoT/DNSCrypt mit ETSI und TLS 1.3 wird die Internet-Nutzung ändern. Mit den Protokollkombinationen können Internet-Provider oder Organisationen keine Webseiten mehr blockieren, da die erforderlichen Informationen nicht mehr zur Verfügung stehen. Hier gilt es noch, erhebliche technische Herausforderungen zu lösen.

Der Autor empfiehlt die folgenden Maßnahmen für Hochschulen und Forschungseinrichtungen:

• Sperren des Ports 53/UDP+TCP für alle Rechner mit Ausnahme der DNS-Server. Das sollte eigentlich schon lange implementiert sein, um den direkten Mailversand von Schadsoftware zu unterbinden.
• Sperren des Ports 853/TCP, um DoT zu unterbinden.
• Beantworten der Anfragen nach der Canary-Domain http://use-application-dns.net mit »NXDOMAIN«.
• Unterbinden der Aktivierung von DoH auf allen verwalteten Rechnern durch Group Policies.
• In Chrome auf allen verwalteten Rechnern den Wert »BuiltInDnsClientEnabled« auf »False« setzen.

Einige Maßnahmen zum Schutz der Privatsphäre, die für Privatnutzer und in öffentlichen Netzen sinnvoll sind, können sich bei Universitäten, Hochschulen, Forschungseinrichtungen, Behörden und Unternehmen kontraproduktiv auswirken. Gerade in den Gästenetzen möchte man Schadsoftware eindämmen, denn die dort verwendeten IP-Adressen gehören schließlich zur Einrichtung. Das Blockieren von Command-und-Control-Systemen oder solcher Server, von denen Schadsoftware Funktionen nachlädt, gehört zu den Standardsicherheitsmaßnahmen und wird häufig durch DNS-Eingriffe realisiert.

DoH wäre auch in Hochschulen und Forschungseinrichtungen akzeptabel, wenn es vom Browser automatisch gegen den oder die im Betriebssystem konfigurierten DNS-Server genutzt würde. Die Einschränkungen durch Group Policies greifen allerdings nur auf verwalteten Systemen der Einrichtung, nicht aber auf BYOD-Geräten. (jcb/jlu)