FAQ: Fragen und Antworten zum kommenden DNS-over-HTTPS (DoH)

FAQ: Fragen und Antworten zum kommenden DNS-over-HTTPS (DoH)

Wenn man sich persönlich für die Entwicklung von Browsern und neuen Webstandards interessiert, dann wird man in den vergangenen Monaten kaum um die Arbeiten an der kommenden DNS-Verschlüsselung herum gekommen sein. Vor allem die intensiven Diskussionen zwischen den jeweiligen Befürwortern von DNS-over-HTTPS und DNS-over-TLS waren immer wieder in den Medien zu finden, wobei sich DNS-over-HTTPS in der Gunst der Entwickler am Ende vorerst durchgesetzt hat. Wir wollen in diesem Beitrag mal ein bisschen Licht ins Dunkel bringen und auch klären, was das für konkrete Auswirkungen für den einzelnen Endnutzer hat, auch wenn er sich sonst kaum oder gar nicht mit solchen Technologien beschäftigt oder davon schlicht keine große Ahnung hat.

Vorab: Die wichtigsten Fragen und Antworten werde ich hier möglichst einfach erklären, damit das auch für die Laien und unerfahreneren Nutzer unter euch möglichst verständlich wird. Sollten aber noch weitere Fragen aufkommen, dann schreibt sie gerne bei uns in die Kommentare. Ich versuche dann, diese dort noch weiter zu beantworten und Unklarheiten auszuräumen.

Was ist DNS-over-HTTPS?

DNS-over-HTTPS, kurz DoH, ist ein neues Netzwerkprotokoll, was im Herbst 2018 von der zuständigen Internet Engineering Task Force (IETF) als neuer Webstandard verabschiedet wurde. Zentrales Ziel des neuen Protokolls ist es, die bisher unverschlüsselten DNS-Abfragen über eine gesicherte Verbindung abzuwickeln und so mehr Sicherheit vor Angriffen wie Man-in-the-Middle zu erreichen. Außerdem soll DoH neben einer verbesserten Leistung auch dabei helfen, DNS-basierte Zensurmaßnahmen einzudämmen.

Neben DoH befindet sich mit DNS-over-TLS, kurz DoT, ein weiteres Protokoll im Standardisierungsverfahren, welches nach derzeitigem Stand noch nicht abgeschlossen ist.

Ist die Verschlüsselung von DNS-Abfragen gründsätzlich neu?

Nein. Mit DNSCrypt gab es auch bisher schon eine Möglichkeit, die aber nur von wenigen Browsern wie dem Yandex Browser nativ angeboten wurden oder mit entsprechenden Programmen in Windows und anderen Betriebssystemen nachinstalliert werden mussten. Standardmäßig werden DNS-Abfragen bis heute über das User Datagram Protocol, kurz UDP, abgewickelt, dessen Entwicklung bereits 1977 began und heute als nicht mehr zeitgemäß gilt. Mit DoH und DoT wurden/werden nun erstmals verbindliche Webstandards verabschiedet, die von den unterschiedlichen Entwicklern in ihre Anwendungen implementiert werden sollen.

Was ist der Unterschied zwischen DoH und DoT?

Bisher werden alle DNS-Abfragen in der Regel noch über das unverschlüsselte UDP-Protokoll abgewickelt, das aufgrund seines Alters und seiner Eigenschaften als nicht mehr zeitgemäß gilt und durchaus als Sicherheitsrisiko betrachtet werden kann. DNS-over-TLS entwickelt den bestehenden Status Quo weiter, indem es die Abfragen über das UDP-Protokoll durch einen gesicherten TLS-Tunnel leitet und so verschlüsselt. Der größte Vorteil von DoT besteht darin, dass dieses Protokoll wesentlich schneller ist und durch die Absicherung mit TLS 1.2 oder TLS 1.3 auf bestehenden Infrastrukturen aufgebaut werden kann.

Wird allerdings DNS-over-HTTPS eingesetzt, wird dabei auch die bestehende Verwertungskette aufgebrochen. Anstatt das UDP-Protokoll weiterhin zu berücksichtigen, baut die jeweilige Anwendung selbst eine HTTPS-Verbindung zum DNS-Server auf und verschlüsselt diese dabei. Dadurch können zwar unter Umständen mehr Bestandteile unter diesen Schutzschirm gezogen werden, gleichzeitig fällt aber auch die Performance gegenüber DoT in manchen Fällen spürbar schlechter aus, was vor allem Nutzer mit langsameren Internetverbindungen spüren werden.

Wie wird DNS-over-HTTPS in Chromium implementiert?

Google testet seit dem Erscheinen von Chrome 78.0 eine erste Implementierung von DoH, wobei der entsprechende Flag nur bei wenigen Nutzern tatsächlich aktiviert wurde. Chrome orientiert sich dabei an den Netzwerkeinstellungen des Nutzers und gleicht diese mit einer Whitelist ab, ob der vorhandene DNS-Anbieter bereits DoH unterstützt. Ist das der Fall und steht der Anbieter auf der Whitelist, wird Chrome automatisch ein Upgrade auf die DoH-Version durchführen. Gleichzeitig werden die eigentlichen DNS-Einstellungen im Betriebssystem nicht verändert und Chrome soll sich auch weiterhin an der Systemebene orientieren. Sollte ein Upgrade nach DoH nicht möglich sein, wird weiterhin die bisherige Ausführung über das UDP-Protokoll verwendet.

Die entsprechende Implementierung ist Teil der Chromium-Basis und steht entsprechend auch anderen Derivaten wie Microsoft Edge, Vivaldi oder Opera zur Verfügung. Dennoch gibt es hier nach einem Bericht von ZDNet.com diverse Unterschiede. Die Umsetzungen in Microsoft Edge, Vivaldi und Brave entsprechen der besagten Standardimplementierung, wobei die Entwickler von Brave nicht ausschließen wollten, dass es noch zu Anpassungen kommt. Einen eigenen Weg gehen die Entwickler bei Opera, die – noch strikter als Mozilla – die DNS-Anfragen über Cloudflare abwickeln und keine Änderungen erlauben. Laut ZDNet.com funktioniert DoH außerdem nicht, wenn der integrierte BrowserVPN genutzt wird.

Welche Pläne verfolgt Mozilla und wieso werden sie dafür stark kritisiert?

Mozilla hat sich bei Firefox für einen Sonderweg entschieden und wird die Umsetzung von DoH vollständig auf der Anwendungsebene implementieren. In den Verbindungseinstellungen kann DoH bereits aktiviert werden, wobei neben Cloudflare als Standardanbieter auch NextDNS sowie ein benutzerdefinierter Anbieter ausgewählt werden können. Anders als Chromium, welches die Nutzereinstellungen berücksichtigt und sich an der Systemebene orientiert, wird Firefox diese Einstellungen vollständig ignorieren, sobald DoH standardmäßig verwendet wird. Das zieht diverse Folgen nach sich.

Die Entwickler weisen darauf hin, dass durch die Implementierung vor allem Sicherheits- und Schutzmechanismen von Firefox ausgehebelt werden können. Neben der Filterung von Malware-Domains oder dem Blocken von Werbung oder Trackern, die auf Systemebene (z.B. über die hosts-Datei) oder im Netzwerk (z.B. über das Pi-hole) umgesetzt werden, gehören dazu auch wichtige Programme wie Kindersicherungen, die von Firefox dann schlicht ignoriert würden. Allerdings soll Firefox von sich aus DNS-over-HTTPS deaktivieren, wenn ein solcher Konflikt erkannt wird, aber es bedeutet auch, dass die Nutzer zwischen verschiedenen Sicherheits- und Schutzmechanismen abwägen müssen, wenn DoH trotzdem eingesetzt werden soll.

Kann ich das Verhalten von Firefox korrigieren?

Ja. Allerdings ist das mit einem gewissen Mehraufwand verbunden, der sicherlich auch nicht für alle Nutzer geeignet ist. Als eine der Möglichkeiten kann man in about:config im Schalter „network.trr.excluded-domains“ bestimmte URLs von DoH ausschließen, was aber angesichts größerer Blocklisten keine gute Lösung von Dauer wäre. Ob das Verhalten von Firefox bei DoH in einigen Punkten generell geändert wird, wird auch schon länger in Bugzilla über den Eintrag 1544233 diskutiert. Allerdings geht es in diesem Punkt bisher auch kaum voran und ein früherer Bug wurde bereits als Wontfix ohne weitere Diskussion geschlossen. Heißt: Damals hatte Mozilla Änderungen abgelehnt, ohne weiter darüber zu sprechen.

Theoretisch wäre vielleicht die beste Möglichkeit, über die benutzerdefinierten Anbieter einen eigenen, lokalen DNS-Server (z.B. über Pi-hole oder den Router) einzustellen, aber ob damit letztlich alle Probleme gelöst werden und DoH auch in Firefox trotzdem verwendet werden kann, ist fraglich. Für alle Nutzer stellt Mozilla sowohl einen Leitfaden zum Konfigurieren von Netzwerken zur Deaktivierung von DoH bereit, als auch ein generelles FAQ zu DNS-over-HTTPS sowie einen Beitrag zur Umsetzung in Firefox selbst.

Was plant eigentlich Microsoft bei DNS-over-HTTPS?

Neben der grundlegenden Unterstützung, die Microsoft Edge an sich schon bietet, hat Microsoft bereits im vergangenen November in Person von Tommy Jensen, Ivan Pashov und Gabriel Montenegro in einem Blogpost angekündigt, dass auch Windows 10 künftig DNS-Verschlüsselung unterstützen wird. Die Vorgehensweise entspricht dabei weitgehend der von Chromium, allerdings betont Microsoft ausdrücklich, dass neben DoH auch andere Methoden wie DNS-over-TLS unterstützt werden können, wenn die Nutzer entsprechendes Feedback geben. Außerdem muss der Fallback auf unverschlüsseltes DNS, also die noch aktuelle Regelung, explizit in den Netzwerkeinstellungen vorgenommen werden.

Microsoft kündigte außerdem an, dass sie in künftigen Meilensteinen unter anderem die Netzwerkeinstellungen verbessern und den Umgang mit Methoden wie DoH optimieren wollen. Weitere Informationen und Entwicklungen sollen auch auf Basis der Nutzerreaktionen erfolgen.

Was passiert bei DoH in Unternehmensnetzwerken und mit Gruppenrichtlinien?

Nichts. Für diese Nutzer wird DNS-over-HTTPS nicht automatisch ausgerollt, es sei denn, die Administratoren geben diese Funktion entsprechend frei.

Was passiert bei Anwendung XYZ, die ebenfalls auf Webtechnologien aufbaut?

Gute Frage. Eines der großen Fragezeichen sind vor allem die Anwendungen, die in irgendeiner Form auch einen Webbrowser zur Darstellung verwenden. Dazu gehören unter anderem die aktuellen AMD Radeon Settings, in denen seit der Adrenalin 2020 Edition auch ein Webbrowser steckt, aber auch Game-Clients wie Steam oder uPlay und diverse Qt-basierte Software wie Falkon oder sogar VLC (VLC verwendet einen minimalen Browser, um den Chromecast ansteuern zu können) gehören dazu. Wie genau sich diese dann verhalten werden, werden wir noch sehen müssen.

Kann ich auch DNS-over-TLS verwenden, wenn ich DNS-over-HTTPS nicht haben möchte?

Teilweise. Momentan wird DoH von nahezu allen Entwicklern besonders forciert, weswegen seine Verbreitung entsprechend auch deutlich größer ist. Dennoch gibt es in diversen Bereichen auch schon eine Unterstützung für DoT, wobei Android dies seit der Android 9.0 Pie im Gegensatz zu DoH auch nativ kann. Grundsätzlich sollte man sich als Nutzer aber darauf einrichten, dass der absolute Schwerpunkt derzeit auf der HTTPS-Umsetzung liegt.

Was sollte ich als Nutzer nun also machen?

Auch wenn man sich sonst nicht so sehr mit den technischen Entwicklungen bei Browsern und Webstandards befasst, lohnt es sich, die weitere Entwicklung von DNS-over-HTTPS mit besonderer Aufmerksamkeit zu verfolgen. Das zentrale Problem liegt hier vor allem darin, dass der neue Standard im Zusammenspiel mit bestimmten Anwendungen wie Kindersicherungen durchaus zu Problemen führen kann und damit nicht zwangsläufig harmonieren muss. Es ist zwar nicht unbedingt zu empfehlen, DoH zu deaktivieren, aber im Zweifelsfall macht es dann Sinn, wenn man zwischen der DNS-Verschlüsselung und elementaren Schutzmechanismen wie einer Kindersicherung abwägen muss.

Generell verfolgen die Chromium-Entwickler und Microsoft bei Windows 10 den deutlich besseren Ansatz, wenn man ihn im direkten Vergleich mit Mozilla und der Firefox-Implementierung betrachtet. Aber so oder so gilt: Nutzer müssen sich darauf einrichten, in den kommenden Monaten bei den Konfigurationen die eine oder andere Veränderung vornehmen zu müssen. Wie umfangreich diese ausfallen müssen, kann man momentan aber noch nicht vollständig abschätzen.

Über den Autor
Kevin Kozuszek
  • Kevin Kozuszek auf Twitter
Seit 1999 bin ich Microsoft eng verbunden, daneben schlägt mein Herz aber auch für die OpenSource-Welt, wo mein besonderes Interesse der Mozilla Foundation gilt. Wenn ich mich mal nicht mit Technik beschäftige, tauche ich gerne in die japanische Kultur mit all ihren Facetten ab oder widme mich einem meiner zahlreichen anderen Hobbies.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.



Kommentare
  1. Obwohl ich eigtl. eher DNS-over-TLS bevorzugen würde, weil es wirklich (spürbar) schneller ist, ist das nervige daran, dass in manchen WLANs / Hotspots der dafür verwendete Port 853 gesperrt ist, sodass dann immer ein Fallback auf unverschlüsselt oder eben gar keine DNS-Auflösung erfolgt. Das trifft insbesondere auch dann zu, wenn da gar keine Sperrabsicht hintersteht, sondern wenn mittels Whitelist gearbeitet wird (z.B. Freigabe von nur Port 80 und 443 in Richtung außen, was ja zum Surfen reicht), da DoT nunmal einen eigenen Port dafür nutzt.
    DoH hingegen läuft über den gleichen Port, über den auch normaler HTTPS-Traffic abgewickelt wird, und kann daher auf diese Weise nicht geblockt werden (dann könnte man in dem Netz nämlich auch keine HTTPS-Seiten erreichen). Darum ist es generell die kompatiblere Lösung, über die man in praktisch jedem Netz verschlüsselt zum DNS kommt.
    Außerdem hat es aus Datenschutzgründen natürlich den nicht von der Hand zu weisenden Vorteil, dass das jeweilige Netz bzw. die Firewall nicht nur nicht den Inhalt der DNS-Abfrage einsehen kann, sondern nicht einmal weiß, dass es sich überhaupt um eine DNS-Abfrage handelt.
    Theoretisch könnte man dadurch in dem Fall eines allzu neugierigen Betreiber eines Netzes diesem gegenüber abstreiten, überhaupt verschlüsselte DNS-Abfragen zu nutzen bzw. diese vor ihm verbergen zu wollen, er könnte nichts Gegenteiliges nachweisen. Das ist ja der Grund, warum DoH von vielen so bevorzugt wird. Bei Nutzung von DoT hingegen weiß jeder Admin sofort was Sache ist und stellt dich gegebenenfalls unter besondere Beobachtung. Etwas, was man z.B. in Ländern mit intensiver Internetzensur gerade nicht haben will.
    @mh0001
    Grundsätzlich habe ich mit DoH auch kein Problem, aber es kommt auch darauf an, dass es in Abstimmung mit den Entwicklern anderer Bereiche schrittweise eingeführt wird. Gerade die Implementierung von Firefox ist da eher ein Bärendienst, wenn man nicht die Vorteile von DoH nutzen kann, ohne Parental Controls und andere Schutzmechanismen außer Kraft zu setzen. Für Eltern wäre Firefox damit ein absolutes NoGo, solange Mozilla das Verhalten von Firefox da nicht dem von Chromium anpasst, deren Ansatz mit der Orientierung an den System- und Netzwerkeinstellungen ja nun wirklich besser ist.
    Die interessante Frage wird vor allem, was mit der hosts-Datei passiert. Der Ansatz von Windows 10 und Chromium ist ja, das Ganze so wenig invasiv wie möglich zu gestalten, und wenn es sich am System und dem Netzwerk orientiert, spricht nichts dagegen, die hosts-Datei trotzdem weiter zu lesen. So oder so macht es aber Sinn, DoT grundsätzlich als Alternative mit umzusetzen. Beides sind ja Webstandards, deswegen müssen sie eigentlich beide so oder so im Browser landen.
    Zumindest bei der Implementierung von DoH im Edge Chromium (hab ich über das experimental Flag aktiviert, nachdem ich Cloudflare 1.1.1.1 systemweit eingestellt hatte; läuft auch laut Cloudflare-Testseite sauber über DoH) läuft das offenbar lokalen DNS-Filteraktivitäten NICHT entgegen.
    Das hat mich zunächst auch etwas erstaunt. Ich benutze ja nicht den Windows Defender sondern Emsisoft, und da ist ein minimal-invasiver Webfilter integriert, der nicht in den (verschlüsselten) Traffic reinschaut, sondern ähnlich wie letztlich HOSTS einfach nur DNS-Anfragen mit einer Datenbank bekannter Malware-Domains abgleicht und gegebenenfalls blockiert. Der Filter basiert auf einem WFP-Treiber, ähnlich zu dem was auch z.B. Adguard benutzt.
    Interessanterweise werden Test-Phishing-Seiten weiterhin blockiert, obwohl Emsisoft die Verschlüsselung von HTTPS-Verbindungen NICHT aufbricht. Die entsprechenden DNS-Anfragen werden auch in der Software angezeigt, obwohl sie von Edge verschlüsselt per DoH rausgehen.
    Das lässt eigtl. nur den Schluss zu, dass zumindest die Implementierung in Edge Chromium die DNS-Anfragen dennoch transparent über WFP filtern lässt, bevor sie dann verschlüsselt werden und ins Netz gehen. Damit würden dann auch Parental Control - Sachen funktionieren.
    Ansonsten, wenn der Browser das wirklich autark für sich alleine verschlüsselt und dann direkt zum DoH-Server schickt, dürften entsprechende Filtermaßnahmen eigtl. nicht funktionieren, jedenfalls nach meinem Verständnis.
    mh0001
    Das lässt eigtl. nur den Schluss zu, dass zumindest die Implementierung in Edge Chromium die DNS-Anfragen dennoch transparent über WFP filtern lässt, bevor sie dann verschlüsselt werden und ins Netz gehen. Damit würden dann auch Parental Control - Sachen funktionieren.
    Ansonsten, wenn der Browser das wirklich autark für sich alleine verschlüsselt und dann direkt zum DoH-Server schickt, dürften entsprechende Filtermaßnahmen eigtl. nicht funktionieren, jedenfalls nach meinem Verständnis.

    Yup, kann ich für Edge, Chrome und Vivaldi (das sind die Chromium-Browser, die ich hier habe), bestätigen. Ich habe bei mir ja auch Cloudflare als DNS-Server systemweit eingetragen, die ja DoH und DoT gleichermaßen schon unterstützen, und meine Einträge in hosts wurden auch nicht ignoriert. Und bei Cloudflare weiß ich sicher, dass sie auf der Whitelist stehen.
    Damit wären Opera und Firefox wohl die Eigenbrödler bei der Umsetzung. Vor allem Firefox würde das nicht gut bekommen, wenn Mozilla sich da nicht noch dreht. Firefox hat in Deutschland als einzigem westlichen Land noch eine größere Nutzerbasis.
    Der Browser ist der falsche Ort für den DNS Client! Der gehört in das OS.
    Ein DNS im Internet löst auch keine lokalen Namen auf.
    Kurzer Hinweis, nachdem ich das auch nochmal getestet habe:
    Opera hat ja auch Cloudflare mit ihrem DoH-Dienst fest verankert und obwohl sie hier einen etwas anderen Weg als andere Chromium-Derivate gehen, muss man zwei Sachen festhalten.
    1. Auch bei Opera muss der gleiche Flag wie bei den anderen Chromium-Browser zusätzlich gesetzt werden und der ist momentan sogar noch deaktiviert, sonst funktioniert es nicht. Sind also zwei Flags.
    2. Wie die anderen Chromium-Browser beachtet Opera auch die lokalen Filterregelungen wie HOSTS und ähnliche Geschichten.
    Das bedeutet unterm Strich, dass Mozilla mit dem Firefox Browser tatsächlich der einzige Vertreter unter den namhaften Browsern ist, der einen komplett eigenen Weg geht und die Einstellungen auf System- und Netzwerkebene ignoriert...
    Und weil das so ist, bleibt es hier, so, wie es war. DNS-Resolver bleibt Router, hosts aktiv, leck mich, es hat so gesehen keinerlei Vorteile. Und da ich Cloudflare nicht mag, die Tracken, auch bei Mozilla - wenn auch weniger - ich nutze im Router Quad9 neben den von der Telekom. Mit dem Policy-Generator von Sören sieht das so aus:
    policies.json
    {
    "policies": {
    "BlockAboutConfig": true,
    "DNSOverHTTPS": {
    "Enabled": false,
    "Locked": true
    },
    "Proxy": {
    "AutoLogin": true,
    "Locked": true,
    "Mode": "none",
    "SOCKSVersion": 4,
    "UseHTTPProxyForAllProtocols": true,
    "UseProxyForDNS": false
    }
    }
    }

    Zuerst sperrt man das about:config, dann DoH und fixiert auf keinen Proxy (beide "locked"). Und dann entzieht man dem anderen die Zugriffsrechte an Programmen. Portables dürfen natürlich auch nicht zugelassen werden ;)
    In Unternehmungen kann man per DoH sogar Netzwerkblockaden aushebeln. (siehe oben)
    Vielen Dank für den Beitrag und den Vergleich.
    Kann mir jemand ganz konkret sagen, warum DoT schneller ist als DoH? Danke.
    ChrisR
    Kann mir jemand ganz konkret sagen, warum DoT schneller ist als DoH? Danke.

    Wenn du die DNS-Abfragen über eine HTTPS-Verbindung schickst, wird zusätzlicher Overhead erzeugt, da die einzelne Anwendung selbst eine HTTPS-Verbindung aufbaut und das klassische UDP-Protokoll ignoriert wird. Es wird also ein größerer Aufwand erzeugt, um die Abfrage zu realisieren und zu sichern. Bei einem TLS-Tunnel passiert das Gleiche wie bei einer einfachen HTTPS-Verbindung im Browser. Da wird eine HTTP-Anwendung durch einen TLS-Tunnel geschickt (allerdings ohne Overhead, der Vorgang ist bei DoH wesentlich intensiver), bei DoT schickst du eine UDP-Anwendung durch den TLS-Tunnel. Deswegen ist DoT schneller.
    Ist übrigens das gleiche Spiel mit FTP und FTPS. FTP ist die unverschlüsselte Variante, FTPS wird durch einen TLS-Tunnel geschickt. Nur SFTP gehört nicht dazu, das ist was Eigenes und basiert auf SSH.
    Einen eigenen Weg gehen die Entwickler bei Opera, die – noch strikter als Mozilla – die DNS-Anfragen über Cloudflare abwickeln und keine Änderungen erlauben.
    Der DoH-Provider lässt sich doch konfigurieren
Nach oben