DoH vs. DoT: Unterschiede und Einsatz im Unternehmen

Wie DoH und DoT funktionieren

DoH kapselt DNS-Nachrichten in HTTPS-Verbindungen. Jede Anfrage/Antwort wird als HTTP-Austausch übertragen. DoH ist in RFC 8484 standardisiert. In der Praxis laufen Verbindungen typischerweise über Port 443 und können HTTP/2 beziehnungsweise HTTP/3 nutzen.

DoT verschlüsselt den DNS-Transport per TLS über eine dedizierte TCP-Verbindung, standardmäßig auf Port 853.

Profile und Authentifizierungsvarianten (Opportunistic/Strict) sind in RFC 7858 und RFC 8310 beschrieben. Die Portzuweisung ist bei IANA registriert.

Sicherheit und Datenschutz

Beide Protokolle verschlüsseln den Inhalt sowie die Integrität der DNS-Transporte auf dem Weg zwischen Client (Stub) und Resolver.  Dadurch können Angreifer im Netz Anfragen nicht mehr im Klartext mitlesen oder manipulieren. Der Vertrauensanker bleibt allerdings der jeweils verwendete Resolver, da dieser weiterhin Ziele sieht und Richtlinien anwenden oder protokollieren kann. Dies gilt unabhängig davon, ob DoH oder DoT genutzt wird. Ein DNS-Resolver ist die Komponente, die für einen Client die Auflösung eines Namens, wie beispielsweise www.computerweekly.de, in technische Daten, wie etwa die IP-Adresse oder den MX-Record, übernimmt.

DoH profitiert von den Sicherheitsmechanismen moderner HTTPS-Stacks (zum Beispiel H2/H3-Features, Padding). Erweiterungen wie Oblivious DoH (ODoH, RFC 9230) entkoppeln zudem Client-IP und DNS-Inhalt über einen Proxy. Das erhöht die Privatsphäre, ist aber komplexer im Betrieb.

Performance und Betrieb

Dank HTTP/2/3 kann DoH mehrere Abfragen über eine einzelne Verbindung multiplexen und profitiert von bestehenden CDN-/TLS-Optimierungen. Das reduziert die Latenz, insbesondere bei vielen parallelen Abfragen. Gleichzeitig kann der HTTP-Overhead den Vorteil in sehr latenzsensitiven Szenarien relativieren.

DoT nutzt dauerhafte TCP+TLS-Sessions auf Port 853, ist technisch einfacher zu erkennen und zu priorisieren, lässt sich klar in Monitoring/Policies abbilden und vermeidet HTTP-Schichten. Die Latenz ist im Alltag meist ähnlich wie bei DoH. Die Unterschiede hängen stark von der Implementierung, der Verbindungswiederverwendung und der Nähe zum Resolver ab.

Netzwerk- und Policy-Aspekte in Unternehmen

In Unternehmensnetzen sind Sichtbarkeit, Richtliniendurchsetzung und effizientes Troubleshooting entscheidend. Die Wahl zwischen DoH und DoT hat Auswirkungen auf Freigaben, Proxy-Design, Monitoring und den Umgang mit internen Zonen (Split-DNS).

• Transparenz/Kontrolle: DoT auf Port 853 ist im Netz eindeutig identifizierbar, was Transparenz und Kontrolle ermöglicht. Das erleichtert interne Freigaben, QoS, Troubleshooting und das Erzwingen bestimmter Resolver. DoH auf Port 443 ist dagegen schwerer von normalem Web-Traffic zu unterscheiden. Dies ist zwar für die Zensurumgehung gewollt, in Unternehmensnetzwerken jedoch oft unerwünscht.
• Proxy-Umgebungen: DoH kann über bestehende HTTPS-Proxies laufen. Das ist in restriktiven Netzen hilfreich, erschwert jedoch das klassische DNS-Monitoring.
• Split-DNS und Compliance: Für interne Zonen ist eine zentrale Kontrolle wichtig. Viele Unternehmen setzen daher auf DoT zu eigenen/vertrauenswürdigen Resolvern, kombiniert mit der Durchsetzung von Richtlinien.

Unterstützung in Betriebssystemen und Anwendungen

Einige Betriebssysteme bieten systemweite DNS-Verschlüsselung, während viele Anwendungen eigene Mechanismen mitbringen. Die BEreitstellung hängt daher von den verfügbaren Optionen auf OS- und App-Ebene ab.

• Android (ab Version 9 mit Private DNS): Systemweite DoT-Unterstützung, konfigurierbar per Authentifizierungs-Domain.
• Browser (Beispiel Firefox): DoH-Support mit unterschiedlichen Schutzstufen, der in unterstützten Regionen automatisch aktiviert und bei Enterprise-Policies/VPN/Elternschutz deaktiviert wird.
• Öffentliche Resolver: Große Anbieter (zum Beispiel Google, Cloudflare) unterstützen sowohl DoT als auch DoH inklusive Praxisdetails zu Methoden (GET/POST), TLS-Profilen und Fallbacks.

Wann sollte man DoH oder DoT verwenden?

Die passende Lösung richtet sich nach der Netzarchitektur, den Compliance-Vorgaben und den Betriebszielen. Hier sind Kriterien, in welchen Fällen DoH oder DoT jeweils Vorteile bieten.

DoT (Port 853) ist vorteilhaft, wenn:

• Sie unternehmensweit einen definierten Resolver durchsetzen und Transparenz im Netzverkehr benötigen (Monitoring, Troubleshooting, QoS).
• Sie Split-DNS für interne Domains betreiben und eine klare Trennung von Web- und DNS-Verkehr wünschen.

DoH (Port 443) ist vorteilhaft, wenn …

• Clients hinter restriktiven Firewalls/Proxies arbeiten und nur HTTPS nach außen erlaubt ist.
• Sie anwendungsspezifische Resolver nutzen möchten (zum Beispiel im Browser), ohne das gesamte System umzuschalten.

In der Praxis kann je nach Umgebung auch eine Kombination sinnvoll sein, etwa systemweit DoT zu unternehmensnahen Resolvern und DoH gezielt in ausgewählten Anwendungen mit dokumentierten Ausnahmen.

DoQ als dritte Option

DNS over QUIC (DoQ, RFC 9250) kombiniert Transportverschlüsselung mit QUIC-Vorteilen (kein Head-of-Line-Blocking, effiziente Verlustbehandlung) und erreicht Latenzwerte, die denen von klassischem UDP-DNS nahekommen – bei ähnlichen Datenschutz-Eigenschaften wie DoT. DoQ nutzt ebenfalls Port 853 (UDP) und findet in Resolver-Software zunehmend Unterstützung. Für neue Installationen kann DoQ perspektivisch interessant sein, wenn Clients/Resolver es bereits unterstützen.

Fazit

Sowohl DoH als auch DoT heben DNS auf ein zeitgemäßes Sicherheitsniveau. DoT bietet sich in Unternehmen für klare Durchsetzung, Sichtbarkeit und Richtlinienkontrolle an. DoH punktet, wenn nur HTTPS durchgelassen wird oder Apps eigenständig verschlüsseltes DNS nutzen sollen. Langfristig kann DoQ zusätzliche Performance-Vorteile bringen.

In der Praxis hat sich häufig ein hybrider Ansatz bewährt: systemweit DoT zu unternehmensnahen Resolvern, flankiert von kontrolliertem DoH-Einsatz in definierten Anwendungen – jeweils mit sauberem Monitoring und dokumentierten Ausnahmen.