DoH – DNS over HTTPS

Abkürzung: DoH

DoH verpackt die Namensauflösung in HTTP. Technisch ist das umständlicher als die Alternative DNS over TLS, die dieselbe Nachricht unverändert über einen eigenen Port schickt. Der Umstand ist Absicht: Weil die Abfrage in gewöhnlichem Webverkehr verschwindet, lässt sie sich nicht gezielt unterdrücken.

Was damit geschützt ist

Die Strecke zwischen der anfragenden Software und dem Resolver. Mehr nicht — die Abfragen des Resolvers nach oben bleiben unverschlüsselt.

Dazu kommt eine Einschränkung, die oft übersehen wird: Nach der Auflösung baut das Gerät eine Verbindung zur ermittelten Adresse auf, und der Hostname steht dabei in der Server Name Indication im Klartext. Wer nur DoH einschaltet, verbirgt die Abfrage und gibt den Namen eine Millisekunde später wieder heraus. Vollständig wirkt es erst zusammen mit Encrypted Client Hello.

Ununterscheidbar von Webverkehr

Für einen Beobachter im Netz sieht eine DoH-Abfrage aus wie der Aufruf einer Webseite: TLS-Verbindung zu Port 443, darin HTTP. Es gibt kein Merkmal, an dem sich DNS-Verkehr herausfiltern ließe.

Wer DoH sperren will, muss daher den Resolverbetreiber als Ganzes ausschließen — also Port 443 zu dessen Adressen blockieren. Das ist möglich, aber es ist eine namentliche Entscheidung gegen einen Anbieter und keine Protokolleinstellung mehr.

Daraus folgt die Eigenschaft, um die gestritten wird: DoH entzieht die Namensauflösung dem Zugriff des Netzbetreibers. Je nach Standpunkt ist das Schutz vor Überwachung oder Verlust einer berechtigten Kontrolle.

Die Entscheidung wandert in die Anwendung

Der zweite Unterschied zu DoT ist, wo konfiguriert wird. DoH ist typischerweise eine Einstellung der Anwendung — des Browsers — nicht des Betriebssystems.

Damit kann ein Programm einen anderen Resolver verwenden als das Gerät, auf dem es läuft. Browser haben verschlüsseltes DNS teils selbst aktiviert und einen eigenen Resolver mitgebracht; die Namensauflösung des Systems bleibt dabei unberührt und ungenutzt.

Für den Nutzer ist der Wechsel unsichtbar. Er hat einen Resolver konfiguriert, und eine Anwendung befragt einen anderen. Das war der Kern der Kritik, als die Voreinstellung eingeführt wurde, und es ist der Grund, warum Browser Rückfallregeln eingebaut haben, mit denen sie die eigene Verschlüsselung in Netzen mit erkennbar eigener Auflösung abschalten.

Wer der Resolver ist

Verschlüsselung beseitigt den Mitleser nicht, sie verschiebt ihn. Vorher sah der Zugangsanbieter alle Abfragen, nachher sieht sie der Betreiber des gewählten Resolvers — vollständig, im Klartext und mit der IP-Adresse des Nutzers.

Die Vertrauensentscheidung liegt also in der Wahl des Resolvers, nicht im Protokoll. Und weil DoH in der Praxis auf eine Handvoll großer Anbieter hinausläuft, verlagert es Abfragen von vielen Zugangsanbietern zu wenigen Betreibern, die dafür jeweils sehr viel mehr sehen.

Entdeckung statt Handarbeit

RFC 9462 beschreibt ein Verfahren, mit dem ein Resolver seine verschlüsselten Zugänge selbst ankündigt: Das Gerät fragt zunächst klassisch nach, erfährt dabei, welche Varianten derselbe Betreiber anbietet, und wechselt darauf.

Das erleichtert den Umstieg, ersetzt aber keine bewusste Entscheidung — der erste Schritt bleibt unverschlüsselt und damit manipulierbar.

Betriebliche Folgen

In verwalteten Netzen bricht DoH mehrere gängige Annahmen, und zwar schwerer als DoT, weil es anwendungsweise greift.

Interne Namen verschwinden. Löst ein Netz eigene Zonen auf, findet eine Anwendung mit externem Resolver diese Namen nicht. Das Fehlerbild ist unauffällig: Das Internet funktioniert, interne Dienste nicht — und nur in einem Programm.

Filter greifen nicht mehr. Sperren für Schadsoftware, Werbung oder Inhalte laufen häufig über den Resolver. Eine Anwendung mit eigenem Resolver umgeht sie.

Die Fehlersuche wird schwerer. Abfragen sind nicht mitlesbar, und welche Anwendung welchen Resolver nutzt, ist am Netzverkehr nicht erkennbar.

Als Gegenmittel bleibt, einen eigenen DoH-Resolver im Netz zu betreiben, der die internen Zonen kennt, und die Anwendungen darauf zu richten — per Richtlinie, denn freiwillig wechseln sie nicht zurück.

Verhältnis zu DNSSEC

Die beiden Eigenschaften sind unabhängig. DoH stellt Vertraulichkeit her, DNSSEC belegt die Echtheit. Gegen DNS-Spoofing auf der Strecke hilft beides, gegen einen Resolver, der selbst falsch antwortet, nur DNSSEC.