Die Kurzfassung: Klassisches DNS (das Protokoll von 1987) sendet Anfragen im Klartext über UDP port 53. Jeder auf dem Netzwerkpfad kann jede Domain lesen, die Sie abfragen, Antworten manipulieren oder bestimmte Anfragen blockieren. DoT (RFC 7858, 2016) kapselt DNS-Anfragen in TLS über port 853. DoH (RFC 8484, 2018) bettet sie in HTTPS-Anfragen auf port 443 ein. Beide lösen das Klartext-Problem. Sie unterscheiden sich darin, wer die Bereitstellung steuert, wer die Anfragen sehen kann und wer sie blockieren kann — und genau das ist die Frage, die die meisten Menschen eigentlich stellen, wenn sie fragen: „Welches soll ich verwenden?" Die Antwort hängt davon ab, wovor Sie sich schützen wollen.
Was DNS-Verschlüsselung behebt — und was nicht
Bevor wir die beiden vergleichen, lohnt es sich klarzustellen, was ein solches Protokoll überhaupt schützt. Klassisches DNS gibt jede Domain preis, die Ihr Gerät abfragt. Besuchen Sie example.com, kann Ihr ISP — oder jeder Netzwerkbetreiber auf dem Weg — die Anfrage für example.com sehen, noch bevor Ihr Browser die erste HTTPS-Anfrage sendet. Der eigentliche Inhalt dieser HTTPS-Anfrage ist verschlüsselt; das vorangehende DNS-Lookup ist es nicht. Verschlüsseltes DNS schließt genau diese Lücke.
Was es nicht behebt: Die Ziel-IP-Adresse, mit der Sie sich verbinden, bleibt sichtbar. Das TLS-Feld Server Name Indication (SNI) verriet in älteren TLS-Versionen den Hostnamen beim Handshake — allerdings adressiert Encrypted Client Hello (ECH) das in TLS 1.3. Verschlüsseltes DNS plus ECH schließt die offensichtlichen Lecks. Ohne ECH schließt verschlüsseltes DNS allein nur ein Leck, lässt aber das SNI-Leck offen, sodass der Ziel-Hostname beim TLS-Handshake weiterhin sichtbar ist. Die ehrliche Einschätzung: Verschlüsseltes DNS ist notwendig, aber nicht hinreichend.
Wie DoT funktioniert — dedizierter Kanal auf port 853
DoT (DNS-over-TLS, definiert in RFC 7858) ist das konzeptionell einfachere Design. Ihr Gerät öffnet eine TCP-Verbindung zum DNS-Server auf port 853. Es führt einen TLS-Handshake durch — dasselbe TLS, das HTTPS schützt — und sendet dann Standard-DNS-Anfragen im verschlüsselten Datenstrom. Der DNS-Server antwortet mit Standard-DNS-Antworten, ebenfalls im verschlüsselten Datenstrom. Aus Sicht des Netzwerks sieht es nur eine TLS-Verbindung auf port 853.
Da port 853 von IANA exklusiv DoT zugewiesen ist, ist jeder TCP-Verkehr auf diesem Port eindeutig DoT. Netzwerkbetreiber können DoT mühelos erkennen — sie brauchen keine Deep Packet Inspection, sondern schauen einfach auf den Zielport. Wollen sie DoT blockieren, verwerfen sie port 853. Wollen sie es zulassen, aber die IP des DNS-Servers protokollieren, ist auch das unkompliziert. DoT bekennt sich offen dazu, DNS zu sein — das ist für manche Anwendungsfälle ein Vorteil und für andere ein Nachteil.
Wie DoH funktioniert — DNS versteckt im Webtraffic
DoH (DNS-over-HTTPS, definiert in RFC 8484) verfolgt einen anderen Ansatz. Ihr Gerät sendet DNS-Anfragen als HTTP-POST-Anfragen (oder GET-Anfragen mit Query-Parameter) an eine bestimmte URL auf dem HTTPS-Server des DNS-Anbieters. Der Body des POST enthält eine binäre DNS-Nachricht; der Response-Body enthält eine binäre DNS-Antwort. Das alles läuft über eine normale HTTPS-Verbindung auf port 443 — demselben Port, den Ihr Browser zum Laden von Webseiten verwendet.
Aus Netzwerksicht ist eine DoH-Anfrage nicht von einer regulären HTTPS-Anfrage an denselben Server zu unterscheiden. Die Verbindung sieht wie Webtraffic aus. Die Paketgrößen sehen wie Webtraffic aus (nach der ersten Anfrage werden Folgeabfragen über dieselbe HTTP/2- oder HTTP/3-Verbindung wiederverwendet). Die Ziel-IP gehört einem generisch wirkenden Endpunkt — Cloudflares 1.1.1.1 oder Googles 8.8.8.8 bedienen DoH und anderen Webtraffic auf denselben IPs. Um DoH gezielt zu blockieren, muss ein Netzwerkbetreiber die spezifischen Endpunkte identifizieren und blockieren, was deutlich schwieriger ist als einen Port zu sperren.
Unterschiede in der Netzwerksichtbarkeit
Der Unterschied im Transport erzeugt einen Unterschied in der Sichtbarkeit. Bei DoT kann Ihr Netzwerkbetreiber (Unternehmens-IT, ISP, Schule, Hotel) sehen, dass Sie verschlüsseltes DNS verwenden, welchen DoT-Server Sie nutzen (anhand der Ziel-IP), und kann diesen Server nach Belieben blockieren. Bei DoH sieht der Netzwerkbetreiber verschlüsselten HTTPS-Verkehr zur IP des DNS-Anbieters — kann aber, sofern er keine Blocklisten für DoH-Endpunkte pflegt, DoH nicht von regulärem HTTPS an denselben Anbieter unterscheiden.
Das hat vorhersehbare Konsequenzen. Unternehmens-IT-Abteilungen bevorzugten jahrelang meist DoT, weil es sich sauber blockieren lässt: port 853 sperren, und DNS fällt auf den Resolver der Organisation zurück, den sie überwachen und filtern. DoH lehnen sie aus demselben Grund ab — es umgeht ihre Sichtbarkeit. Datenschutzadvokaten für Verbraucher bevorzugen DoH genau aus diesem Grund. Unterschiedliche Interessengruppen erwarten unterschiedliche Ergebnisse von derselben Architekturentscheidung.
Welches Protokoll Netzwerke blockieren können
DoT ist einfach zu blockieren. Port 853 wird ausschließlich dafür verwendet; eine Firewall-Regel, die ihn verwirft, genügt. Viele Unternehmensnetzwerke tun das bereits. Viele Filterfirewalls in restriktiven Regionen ebenfalls. Wenn Sie ein Gerät auf DoT konfigurieren und das Netzwerk port 853 sperrt, schlagen DNS-Anfragen des Geräts fehl, bis das Betriebssystem oder die App auf unverschlüsseltes DNS zurückfällt — und die meisten tun das still und heimlich.
DoH ist deutlich schwerer zu blockieren, weil der einzige Weg darin besteht, jeden DoH-Endpunkt zu identifizieren und auf eine Blockliste zu setzen. Cloudflares 1.1.1.1 ist der bekannteste und steht meist auf der Blockliste; Googles 8.8.8.8 typischerweise auch. Aber unabhängig betriebene DoH-Endpunkte vermehren sich — öffentliche Listen wie das DoH-Wiki von curl verzeichnen Hunderte davon. Ein Netzwerkbetreiber, der DoH global blockieren will, muss diese Liste aktuell halten und akzeptieren, dass er neuen Endpunkten immer einen Schritt hinterherhinkt. Manche restriktiven Netzwerke versuchen DoH durch Verkehrsmuster-Analyse zu erkennen (DoH weist charakteristische Anfragegrößen und Timings auf), aber das ist fehleranfällig und produziert falsche Positive.
Mozillas DoH-Dokumentation nennt diese Eigenschaft — dass DoH für Netzwerke schwer zu blockieren ist — ausdrücklich als bewusstes Designziel, nicht als Nebeneffekt. Dieselbe Eigenschaft macht DoH in Unternehmensumgebungen umstritten, wo der Netzwerkbetreiber DNS-Sichtbarkeit als legitimen Teil seines Sicherheits-Stacks betrachtet und nicht als Verletzung der Privatsphäre der Nutzer.
Auswirkungen auf Unternehmen und Kindersicherung
DNS-basiertes Filtern — die Technik, die die meiste Kindersicherungssoftware, unternehmensseitige „Safe-Browsing"-Filter und die einfachsten Formen der Malware-Domain-Blockierung antreibt — funktioniert, indem DNS-Anfragen abgefangen werden und entweder die für gesperrte Domains verworfen oder gefälschte Antworten zurückgegeben werden. Die Mechanik haben wir in unserem Artikel über die tatsächliche Funktionsweise von DNS-basiertem Filtern erläutert.
Verschlüsseltes DNS umgeht das vollständig — sowohl DoT als auch DoH leiten Anfragen an einen anderen Resolver als den des lokalen Netzwerks weiter, sodass jegliches Filtern am lokalen Resolver wirkungslos ist. Aus Sicht von Kindersicherungs-Anbietern ist das ein Problem. Aus Nutzersicht hängt es vollständig davon ab, ob man das Filtern als legitim oder als übergriffig betrachtet. Die meisten modernen Enterprise-Endpoint-Management-Tools deaktivieren Browser-DoH per Richtlinie und setzen entweder auf DNS-Konfiguration auf Betriebssystemebene oder vollständige Verkehrsinspektion, um die Sichtbarkeit zu wahren. Apples MDM-verwaltete iOS-Profile enthalten einen DoH/DoT-Konfigurationsmechanismus, der genau dafür gedacht ist: Das Unternehmen kann einen verschlüsselten DNS-Resolver seiner Wahl festlegen und Nutzer daran hindern, ihn zu überschreiben.
In Privathaushalten ist die praktische Realität diese: DoH in einem Browser zu aktivieren, umgeht jegliches routerbasiertes Inhaltsfiltern, das man eingerichtet hat. Ob das eine Funktion oder ein Fehler ist, hängt davon ab, auf welcher Seite der Konfiguration man sitzt.
Performance-Eigenschaften
DoT hat typischerweise einen etwas geringeren Overhead pro Anfrage als DoH. Beide Protokolle verwenden TLS, aber DoT legt einen deutlich kleineren Rahmen um jede DNS-Nachricht — es gibt keine HTTP-Anfragezeile, keine Header, kein Content-Length, keine HTTP-Methode. Die DNS-Nachricht geht direkt in den TLS-Datenstrom. DoH hingegen kapselt jede DNS-Anfrage in einen HTTP-POST oder GET, was dutzende bis hunderte Bytes zusätzlichen Overhead pro Anfrage bedeutet.
Dieser Overhead wird durch Verbindungswiederverwendung weitgehend ausgeglichen. Sowohl DoT als auch DoH halten die TLS-Verbindung über viele Anfragen hinweg offen, sodass die Handshake-Kosten nur einmal anfallen. DoH über HTTP/2 multiplext Anfragen über dieselbe Verbindung, und HTTP/3 (über QUIC) reduziert die Latenz weiter. In der Praxis produzieren beide Protokolle auf einem modernen Netzwerk für den Nutzer nicht unterscheidbare Latenzen — höchstens ein paar Millisekunden Unterschied. Wählen Sie keines der beiden aus Performance-Gründen; die Wahl dreht sich um Sichtbarkeit, Kontrolle und Ihr Bedrohungsmodell.
DoT vs DoH auf einen Blick
| Eigenschaft | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Port | 853 (dediziert) | 443 (geteilt mit HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transport | Reines TLS über TCP | HTTPS (HTTP/2 oder HTTP/3) |
| Im Netzwerk erkennbar | Ja — port 853 ist eindeutig DoT | Nein — sieht aus wie normales HTTPS |
| Blockierbarkeit durch das Netzwerk | Einfach (port 853 sperren) | Schwer (erfordert Endpunkt-Blockliste) |
| Browser-Unterstützung | Nein (Browser implementieren DoT nicht) | Firefox, Chrome, Edge, Safari unterstützen es alle |
| Betriebssystem-Unterstützung | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Sichtbarkeit für Unternehmen | Per Port sichtbar; einfach zu überwachen oder zu blockieren | Umgeht portbasiertes Monitoring; erfordert Endpunkt-Inspektion |
| Latenz-Overhead pro Anfrage | Geringer (minimaler Wrapper) | Etwas höher (HTTP-Header); vernachlässigbar mit HTTP/2-Multiplexing |
| Zensurresistenz | Gering (per Port blockierbar) | Höher (port 443 ist für das moderne Web unverzichtbar) |
Welches sollten Sie verwenden — drei Szenarien
„Welches Protokoll ist besser" hängt vollständig davon ab, was Sie erreichen wollen. Hier sind drei konkrete Szenarien mit konkreten Antworten:
Szenario 1: Persönliches Gerät in feindlichen oder nicht vertrauenswürdigen Netzwerken
Cafés, Hotels, Flughäfen, das WLAN von Freunden. Das Bedrohungsmodell ist der lokale Netzwerkbetreiber, der Ihr DNS beobachtet oder manipuliert. Für die Verschlüsselung selbst funktioniert jedes Protokoll; DoH ist vorzuziehen, weil es für ein feindliches Netzwerk deutlich schwerer zu blockieren ist. Wenn Sie DoT in einem Netzwerk nutzen, das port 853 sperrt, fallen Ihre Anfragen still auf Klartext auf port 53 zurück (die meisten Betriebssystem-Clients verhalten sich so) — und Sie haben alles preisgegeben, was Sie schützen wollten. DoH erreicht seinen Endpunkt fast immer.
Szenario 2: Heimnetzwerk mit verwalteten Kindergeräten
Sie wollen, dass die Geräte der Kinder einen filternden DNS-Resolver verwenden (NextDNS, OpenDNS Family Shield, Cloudflare for Families), und sie sollen ihn nicht umgehen können. DoT ist hier eigentlich einfacher — Sie konfigurieren das Gerät auf einen bestimmten DoT-Resolver, und das Kind kann nicht unkompliziert eine Einstellung im Browser ändern, um ein anderes DNS zu nutzen. Browser-DoH lässt sich per Enterprise-/MDM-Richtlinie oder durch Setzen der Canary-Domain deaktivieren. Die Wahl zwischen DoT und DoH ist weniger entscheidend als die DNS-Konfiguration auf Betriebssystemebene, statt einzelnen Apps die freie Wahl zu lassen.
Szenario 3: Sie betreiben bereits ein VPN
Wenn Sie ein VPN verwenden, kann das lokale Netzwerk Ihre DNS-Anfragen ohnehin nicht sehen — der VPN-Tunnel verschlüsselt alles, einschließlich DNS. Die relevante Frage ist dann, welchen DNS-Resolver das VPN intern verwendet und ob er verschlüsseltes DNS zu seinem Upstream-Resolver unterstützt. Die meisten modernen VPNs (darunter Casper's Cloak) verwenden intern verschlüsseltes DNS und wenden Threat-Shield-Filterung am Resolver an, bevor die Antwort durch den Tunnel zurückgesendet wird. In dieser Konfiguration ist DoT vs DoH größtenteils ein Implementierungsdetail; entscheidend ist, dass der Resolver nicht Ihr ISP ist und Ihre Anfragen nicht protokolliert.
Die Vertrauensfrage, die beide Protokolle umgehen
Sowohl DoT als auch DoH verlagern das Vertrauen vom lokalen Netzwerkbetreiber auf den verschlüsselten DNS-Anbieter Ihrer Wahl. Cloudflare, Google, Quad9, NextDNS, ControlD — jedes dieser Unternehmen sieht jede DNS-Anfrage, die Sie an sie senden. Verschlüsselung gegenüber ihnen bedeutet keine Privatsphäre vor ihnen. Wenn Ihr Anliegen ist, dass Ihr ISP Ihr DNS nicht sehen soll, löst verschlüsseltes DNS das Problem. Wenn Ihr Anliegen ist, dass kein Dritter Ihr DNS sehen soll, hilft keines der Protokolle; Sie müssten einen eigenen rekursiven Resolver betreiben — was ein eigenes Projekt ist.
Was Sie von dem Resolver verlangen können, dem Sie vertrauen: eine klare Protokollierungsrichtlinie, Prüfungen durch Dritte, Unterstützung für Query Minimization (damit die autoritativen Upstream-Server nur die Teile der Anfrage sehen, die sie benötigen) und DNSSEC-Validierung. Die großen öffentlichen DoH/DoT-Anbieter veröffentlichen alle ihre Richtlinien — lesen Sie sie. Unseren ausführlicheren Leitfaden dazu finden Sie in unserem DoH-Bericht 2026.
Fazit
DoT und DoH lösen dasselbe grundlegende Problem — dass DNS im Klartext Ihre Browsing-Ziele ans Netzwerk verrät — mit zwei unterschiedlichen Architekturstrategien. DoT ist das ehrliche Design: ein dedizierter Port, leicht erkennbar, leicht verwaltbar, leicht blockierbar. DoH ist das getarnte Design: versteckt im HTTPS-Verkehr, ohne Endpunkt-Blocklisten schwer erkennbar, im großen Maßstab kaum zu blockieren.
Für Verbraucher in feindlichen Netzwerken ist DoH die richtige Wahl, weil es das Protokoll ist, das seinen Endpunkt tatsächlich erreicht. Für Unternehmen, die DNS-Sichtbarkeit benötigen, ist DoT die kooperativere Wahl. Für Menschen, die zu Hause ein eigenes filterndes DNS betreiben, ist DoT konfigurierbarer und für Nutzer schwerer auf App-Ebene zu umgehen. Für VPN-Nutzer ist die Wahl größtenteils unsichtbar — der VPN-Client übernimmt das.
Die eigentliche Frage ist selten „DoT oder DoH" — sie lautet: „Welchem Resolver vertraue ich, und wie lautet seine Protokollierungsrichtlinie?" Wählen Sie einen Resolver, dem Sie vertrauen, konfigurieren Sie ihn systemweit (nicht pro Browser), und überprüfen Sie mit einem DNS-Leak-Test, ob die Konfiguration tatsächlich korrekt übernommen wurde. Das Protokoll, über das Sie mit ihm kommunizieren, ist weniger entscheidend als die Richtlinie des Unternehmens am anderen Ende.