DoH (DNS over HTTPS)
Protokoll nach RFC 8484, das DNS-Abfragen über verschlüsselte HTTPS-Verbindungen auf Port 443 überträgt und so verhindert, dass Internetprovider, Netzwerkbetreiber oder Angreifer auf dem Übertragungsweg den DNS-Verkehr mitlesen oder manipulieren können.
DNS over HTTPS (DoH) ist ein in RFC 8484 spezifiziertes Protokoll, das DNS-Abfragen nicht mehr unverschlüsselt über UDP-Port 53 sendet, sondern in reguläre HTTPS-Verbindungen einbettet. Die Abfrage reist damit über Port 443 — denselben Port, den jede andere gesicherte Webkommunikation nutzt — und ist für Außenstehende nicht von normalem Web-Traffic zu unterscheiden. DoH ergänzt DNSSEC um eine Vertraulichkeitsdimension: Während DNSSEC die Integrität und Authentizität von DNS-Antworten absichert, schützt DoH den Übertragungsweg selbst vor dem Mitlesen.
Das Problem: DNS im Klartext
Das ursprüngliche DNS-Protokoll aus den 1980er Jahren sendet alle Abfragen unverschlüsselt. Wenn ein Mitarbeiter im Firmennetzwerk bank.de aufruft, sieht der Internetprovider, der Netzwerkbetreiber und jeder Angreifer im Netzwerkpfad genau, welche Domain angefragt wird — lange bevor eine eigentliche HTTP-Verbindung zustande kommt. Selbst wenn die Webkommunikation anschließend über TLS gesichert ist, bleibt der DNS-Lookup ein sichtbares Metadatenfenster. Dieses Muster erlaubt es, Nutzerprofile zu erstellen, Inhaltsfilter zu umgehen oder gezielt Datenverkehr zu manipulieren.
Internetprovider können auf Basis unverschlüsselter DNS-Daten Nutzungsprofile anlegen. Angreifer in öffentlichen WLAN-Netzen können DNS-Antworten fälschen und Nutzer auf betrügerische Server umleiten — ein Angriff, der ohne DNSSEC-Validierung leicht möglich ist. Auch in Unternehmensnetzen kann ein kompromittierter Router oder Switch als passiver Abhörpunkt für DNS-Traffic fungieren.
Wie DoH funktioniert
DoH überträgt DNS-Abfragen als HTTPS-POST- oder GET-Requests an einen DoH-Resolver. Die Abfrage ist im DNS-Wire-Format kodiert und wird als MIME-Typ application/dns-message übertragen. Der Resolver — häufig ein öffentlicher Dienst wie Cloudflare (1.1.1.1) oder Google (8.8.8.8) — antwortet ebenfalls über die gesicherte HTTPS-Verbindung mit der aufgelösten IP-Adresse.
Da der gesamte Austausch über Port 443 läuft und durch TLS verschlüsselt ist, sieht ein passiver Beobachter lediglich, dass eine HTTPS-Verbindung zum DoH-Resolver besteht — nicht aber, welche Domains abgefragt werden. Für den Resolver selbst ist die Abfrage natürlich im Klartext sichtbar; das Vertrauen verlagert sich also vom lokalen Netzwerkbetreiber auf den DoH-Anbieter.
DoH vs. DoT: Zwei Wege zur verschlüsselten Namensauflösung
DNS over TLS (DoT, RFC 7858) löst dasselbe grundlegende Problem wie DoH, wählt aber einen anderen technischen Ansatz. DoT verschlüsselt DNS-Abfragen ebenfalls mit TLS, nutzt dafür jedoch einen eigenen dedizierten Port: TCP-Port 853.
| Merkmal | DoH (RFC 8484) | DoT (RFC 7858) |
|---|---|---|
| Port | 443 (HTTPS) | 853 (eigener Port) |
| Protokoll | HTTPS | TLS over TCP |
| Sichtbarkeit | Nicht von Web-Traffic unterscheidbar | Als DNS-Traffic erkennbar |
| Blockierbarkeit | Schwieriger zu blockieren | Leicht per Firewall-Regel zu sperren |
| Enterprise-Kontrolle | Aufwendiger | Einfacher filterbar |
| Browser-Integration | Nativ in Firefox, Chrome, Edge | Betriebssystemebene oder Stub-Resolver |
DoH ist für Endnutzer in feindseligen oder restriktiven Netzwerken schwieriger zu blockieren, weil er sich in regulären HTTPS-Traffic einmischt. Für Unternehmensumgebungen ist genau das eine Herausforderung: Netzwerkadministratoren können DoT einfach durch Sperren von Port 853 kontrollieren, während DoH spezifischere Maßnahmen erfordert. DoT ist daher im Enterprise-Umfeld oft bevorzugt, DoH in konsumentenorientierten Anwendungsfällen und Browsern dominanter.
DoH und DNSSEC: Komplementäre Schutzmechanismen
DoH und DNSSEC ergänzen einander, lösen aber unterschiedliche Probleme. DNSSEC stellt sicher, dass eine DNS-Antwort authentisch und unmanipuliert ist — es signiert die Daten kryptografisch und ermöglicht dem Resolver die Verifizierung der Antwort anhand der hierarchischen Vertrauenskette. DoH schützt die Vertraulichkeit des Übertragungswegs: Es verhindert, dass Dritte sehen, welche Abfragen gestellt werden.
Beide Mechanismen schließen einander nicht aus und sollten idealerweise gemeinsam eingesetzt werden. Ein Angreifer, der DoH-verschlüsselten Traffic mitlesen könnte, würde von DNSSEC an der Manipulation gehindert. Umgekehrt schützt DoH vor dem Mitlesen von DNS-Abfragen, selbst wenn DNSSEC nicht für alle angefragten Domains aktiviert ist. In einer vollständigen Sicherheitsarchitektur sind beide Protokolle sinnvoll: DNSSEC als Integritätsgarantie, DoH als Vertraulichkeitsschicht.
Für Unternehmen, die DANE für die Absicherung ihrer E-Mail-Transportverschlüsselung nutzen, ist DNSSEC die zwingende Voraussetzung — DoH kann parallel dazu für den internen Resolver-Verkehr eingesetzt werden, ohne DANE zu beeinträchtigen.
Datenschutz und Vertrauensverschiebung
DoH verbessert die Privatsphäre gegenüber unverschlüsseltem DNS erheblich, löst das Vertrauensproblem jedoch nicht vollständig — es verlagert es. Ohne DoH kennt der lokale Netzwerkbetreiber oder Internetprovider alle DNS-Abfragen. Mit DoH sieht stattdessen der gewählte DoH-Resolver das vollständige Abfrageprofil. Wer 1.1.1.1 von Cloudflare oder 8.8.8.8 von Google nutzt, vertraut diesen Anbietern, dass sie Abfragen nicht protokollieren oder anderweitig verwerten.
Aus DSGVO-Perspektive ist diese Verschiebung relevant: Wenn Mitarbeiter eines deutschen Unternehmens über öffentliche DoH-Resolver kommunizieren, werden personenbezogene Metadaten — DNS-Abfragen lassen Rückschlüsse auf besuchte Websites und Kommunikationspartner zu — an US-amerikanische Anbieter übertragen. Unternehmen sollten daher prüfen, ob sie einen eigenen DoH-Resolver oder einen DSGVO-konformen Anbieter einsetzen möchten. Betriebseigene Resolver auf Basis von Software wie Unbound oder Pi-hole mit DoH-Unterstützung sind datenschutzfreundlichere Optionen. Auch europäische DNS-Anbieter, die DoT oder DoH unterstützen, können eine Alternative zu US-Diensten darstellen.
Das BSI befasst sich mit DoH im Kontext seiner Empfehlungen zur sicheren DNS-Konfiguration. In seinen Mindeststandards und technischen Richtlinien betont das BSI die Bedeutung verschlüsselter DNS-Kommunikation für behördliche und kritische Infrastrukturen, empfiehlt jedoch gleichzeitig, die Kontrolle über den DNS-Resolver im eigenen Verantwortungsbereich zu halten, anstatt Abfragen unkontrolliert an externe Drittanbieter auszulagern.
Enterprise-Überlegungen: DoH und Split-DNS
DoH stellt Unternehmens-IT-Teams vor besondere Herausforderungen. Viele Unternehmen betreiben Split-DNS-Architekturen: Interne Hostnamen und Ressourcen werden über interne DNS-Server aufgelöst, während externe Abfragen über den Unternehmens-Resolver laufen — oft mit Inhaltsfilterung, Protokollierung und Malware-Blocking. Wenn Mitarbeiter oder Anwendungen DoH mit einem externen Resolver verwenden, umgehen sie diese interne DNS-Infrastruktur vollständig.
Das hat praktische Konsequenzen: Interne Hostnamen wie intranet.firma.local können über externe DoH-Resolver nicht aufgelöst werden, was zu Verbindungsfehlern führt. Sicherheitswerkzeuge, die DNS-Anfragen als Erkennungsvektor nutzen — etwa SIEM-Systeme, die DNS-Lookups auf bekannte Command-and-Control-Server überwachen — verlieren ihre Sichtbarkeit, wenn der Traffic verschlüsselt an einen externen Resolver geht.
Sicherheitsteams haben grundsätzlich drei Handlungsoptionen: Sie können DoH gezielt für bekannte externe Resolver-IPs oder deren SNI-Namen blockieren, einen eigenen DoH-Resolver betreiben, auf den alle Clients konfiguriert werden, oder Endpoint-Management-Lösungen nutzen, um Browser- und Betriebssystem-DoH-Einstellungen zentral zu steuern. Microsoft empfiehlt für Windows-Umgebungen die Konfiguration eines internen DoH-Resolvers über Gruppenrichtlinien, um die Vorteile verschlüsselter DNS-Kommunikation beizubehalten und gleichzeitig die Kontrolle zu wahren.
Browser-Support und Konfiguration
Die großen Browser haben DoH als Standard-Feature eingeführt. Firefox war der Vorreiter und aktiviert DoH standardmäßig in den USA; in anderen Regionen lässt es sich in den Netzwerkeinstellungen aktivieren und mit einem eigenen Resolver-Endpunkt konfigurieren. Google Chrome und Microsoft Edge unterstützen DoH ebenfalls nativ und bieten eine Option zur Auswahl aus einer Liste vorkonfigurierter Resolver oder zur Eingabe eines benutzerdefinierten Endpunkts.
Auf Betriebssystemebene unterstützt Windows seit Version 11 nativ DoH-Konfiguration über die Netzwerkeinstellungen und Gruppenrichtlinien. macOS und iOS unterstützen DoH ebenfalls, primär über Konfigurationsprofile. Linux-Nutzer können DoH über externe Tools wie dnscrypt-proxy oder cloudflared einrichten, die als lokaler Resolver fungieren. systemd-resolved unterstützt ab Version 239 DoT nativ, für DoH ist jedoch ein separater lokaler Resolver erforderlich.
Für Unternehmen empfiehlt sich die zentrale Konfiguration über Mobile Device Management (MDM) oder Gruppenrichtlinien, um sicherzustellen, dass alle Geräte einen einheitlichen — und kontrollierten — Resolver nutzen. Ein unkontrollierter Mix aus verschiedenen externen DoH-Resolvern, die Mitarbeiter eigenständig in ihren Browsern konfigurieren, erschwert das Monitoring und kann Sicherheitskontrollen aushöhlen.
Relevanz für KMUs
Für kleine und mittelständische Unternehmen ist DoH vor allem in zwei Szenarien relevant. Erstens schützt DoH im mobilen Arbeiten — etwa wenn Mitarbeiter im Homeoffice oder über öffentliche WLAN-Netze arbeiten — vor dem Mitlesen von DNS-Anfragen durch den lokalen Netzwerkbetreiber. In Kombination mit einem VPN entsteht eine robuste Grundlage für sicheres Remote-Working. Zweitens sollten Unternehmen, die einen eigenen DNS-Resolver betreiben oder Inhaltsfilterung über DNS umsetzen, sicherstellen, dass DoH in Browsern und Betriebssystemen nicht unkontrolliert externe Resolver nutzt und so die internen Sicherheitskontrollen umgeht.
Unternehmen, die ihre DNS-Konfiguration prüfen möchten, können mit dem DNSSEC-Check feststellen, ob ihre eigene Domain DNSSEC-gesichert ist — die Grundlage für weiterführende DNS-Sicherheitsmechanismen. Der E-Mail Security Check gibt Aufschluss darüber, ob die DNS-basierten E-Mail-Sicherheitsprotokolle SPF, DKIM und DMARC korrekt konfiguriert sind. Für eine umfassende Bewertung der Netzwerksicherheit, einschließlich der DNS-Infrastruktur, empfiehlt sich ein professionelles Assessment der Netzwerksicherheit.