DoH3, DoQ und DoT: Was sich Ende 2025 ändert

Von CaptainDNS
Veröffentlicht am 1. Dezember 2025

#DNS
#DoH
#DoT
#DoQ
#Sicherheit

Schema, das DoH3, DoQ und DoT in einer modernen DNS-Architektur vergleicht

TL;DR

DoT ist zur breit ausgerollten Basis des verschlüsselten DNS geworden, während DoH3 und DoQ QUIC als Transport für DNS-Abfragen etablieren.
Ende 2025 aktivieren immer mehr Betriebssysteme, Browser und Resolver verschlüsseltes DNS standardmäßig, wodurch die Sichtbarkeit auf dem klassischen Port 53 sinkt.
Diese Entwicklungen wirken direkt auf die Unternehmens-DNS-Architektur: Resolver, Firewalls, Proxys, Observability und Compliance müssen angepasst werden.
Es geht nicht darum, „einen Sieger zu wählen“, sondern um eine Multi-Transport-Strategie: DoT als Basis, DoH3 und DoQ dort, wo Latenz, Resilienz und Mobilität kritisch sind.

Kontext: vom Klartext-DNS zum verschlüsselten DNS

Über Jahrzehnte lief DNS-Resolution größtenteils im Klartext über UDP/TCP 53. Das vereinfachte Debugging und Netzfilterung, öffnete aber Tür und Tor für Mithören, gefälschte Antworten und massives Traffic-Profiling.

Mit dem Fokus auf Privatsphäre und dem Siegeszug von TLS im Web folgte DNS derselben Spur: Zuerst Verschlüsselung der „letzten Meile“ zwischen Client (Stub-Resolver) und rekursivem Resolver, dann der Einsatz moderner Transporte wie QUIC.

Ende 2025 prägen drei Bausteine das Bild des verschlüsselten DNS von Client → Resolver: DoT, DoH (inklusive DoH3) und DoQ. Ihre Unterschiede zu kennen ist entscheidend, um Auswirkungen auf Architekturen abzusehen.

Kurzer Überblick: DoT, DoH, DoH3 und DoQ

Klassisches DNS (UDP/TCP 53)

Historisches DNS nutzt UDP 53 für die meisten Abfragen und TCP 53 als Fallback für Zonentransfers (XFR) und große Antworten. Das ist simpel und schnell, aber komplett unverschlüsselt: Ein Netzbeobachter kann Domainnamen sehen, falsche Antworten injizieren oder bestimmte Abfragen blockieren.

DNS over TLS (DoT)

DoT kapselt DNS in einen TLS-Stream (typisch auf TCP 853) zwischen Client und Resolver. Standardisiert im RFC 7858, soll es Mithören und Manipulation auf dem Netzwerkpfad verhindern.

Praktisch gilt für DoT:

eigener TCP/TLS-Kanal (Port 853);
Vertraulichkeit ähnlich einem „klassischen“ HTTPS;
breite Unterstützung bei großen öffentlichen Resolvern und vielen Open-Source-Resolvern.

DoT ist heute das reifste Fundament für verschlüsseltes DNS auf der Infra-Seite, auch weil es konzeptionell nahe am bekannten Duo DNS + TLS bleibt.

DNS over HTTPS (DoH) und DoH3

DoH transportiert DNS-Abfragen über HTTPS (RFC 8484), also auf Port 443, in einem HTTP/2- oder HTTP/3-Kanal. Die DNS-Nachricht steckt im HTTP-Body, sodass man die gesamte Web-Stack nutzen kann: HTTP-Proxys, Authentifizierung, CDN usw.

Läuft DoH über HTTP/3 (selbst auf QUIC), spricht man oft von „DoH3“:

gleiche DNS-Semantik wie DoH;
gleicher Port 443 wie Web-Traffic, daher schwieriger zu filtern;
gleiche QUIC-Vorteile: mögliches 0-RTT, bessere Verlustbehandlung, effizientes Multiplexing.

DoH3 ist besonders für Browser und bestimmte Apps interessant, weil es DNS im bestehenden HTTPS-Fluss versteckt und gleichzeitig von QUIC profitiert.

DNS over QUIC (DoQ)

DoQ nutzt QUIC direkt als DNS-Transport ohne HTTP. Definiert im RFC 9250, kombiniert es:

Vertraulichkeit ähnlich einem TLS-Kanal (wie DoT);
Performance und Resilienz von QUIC: kein Head-of-Line-Blocking auf Transportebene, bessere Verlustbehandlung, natives 0-RTT und Mobilität.

In der Praxis:

DoQ verwendet typischerweise UDP-Port 853, historisch bereits mit DNS-over-TLS/DTLS verbunden;
jede QUIC-Verbindung kann mehrere DNS-Abfragen multiplexen;
das Protokoll passt besonders zu Netzen mit variabler Latenz (dichtes WLAN, Mobilfunk, etc.).

Was sich Ende 2025 wirklich ändert

Neu ist nicht die Existenz von DoT, DoH oder DoQ—alle sind seit Jahren standardisiert—sondern ihr Verbreitungsgrad und die Standardaktivierung.

Kurzgefasst:

DoT ist das „Baselayer“ des verschlüsselten DNS für rekursive Resolver und Managed Services.
DoH wird breit von Browsern, OS und App-Bibliotheken unterstützt; HTTP/3 (DoH3) gewinnt an Fahrt.
DoQ verlässt die Experimentierphase und wird auf modernen rekursiven Servern zur seriösen Option, insbesondere in latenz- und resilienzsensiblen Umgebungen.

Diese Trends haben konkrete Folgen für Netz/DNS-Teams.

1. QUIC wird ein DNS-Transport erster Klasse (DoH3 und DoQ)

QUIC betrifft nicht mehr nur Web-Traffic: Ein wachsender Anteil der DNS-Resolutionen zwischen Client und Resolver läuft über HTTP/3 (DoH3) oder DoQ.

Wesentliche Auswirkungen:

Latenz: 0-RTT + kein Head-of-Line-Blocking auf Transportebene verkürzen die wahrgenommene Auflösungszeit, besonders bei Verlusten oder schwankender Latenz.
Stabilität: QUIC verkraftet IP-Adresswechsel (WLAN ↔ 4G/5G) besser, weil die logische Verbindung erhalten bleibt.
Filterfläche: „DNS blocken“ bedeutet nicht mehr nur UDP/TCP 53; QUIC auf 443 (DoH3) und UDP 853 (DoQ) gehören dazu.

In Unternehmensarchitekturen müssen DNS-Filterregeln Transporte berücksichtigen, nicht nur historische Ports.

2. Verschlüsseltes DNS wird Standard in OS und Browsern

Moderne Betriebssysteme (Desktop, Mobile, Server) bieten native Optionen, DoT oder DoH zu aktivieren, teils systemweit, teils pro Anwendung (Browser, VPN-Client, Security-Agent).

Folgen:

Manche Endgeräte können beginnen, den Unternehmens-Resolver zu umgehen, um direkt öffentliche Resolver per DoH3/DoT zu befragen.
Je nach Richtlinie kann das Logging-, Compliance- oder Filteranforderungen (Security-Proxy, DLP, etc.) widersprechen.
IT-Teams müssen klar entscheiden: Welche Flüsse zu externen Resolvern sind erlaubt, über welche Transporte, und in welchen Fällen?

3. Observability und Debugging werden schwieriger

Mit verschlüsseltem DNS lassen sich Inhalte zwischen Client und Resolver auf dem Netzpfad nicht mehr einsehen, ohne kontrollierte TLS/QUIC-Termination.

Betroffen sind:

Capture-/Analysetools (tcpdump, Wireshark, NDR-Sonden);
„Notfall“-Debugging (unerwartetes Filtering, inkonsistente TTLs, Cache-Divergenzen zwischen internen und externen Resolvern);
Korrelation zwischen DNS-Logs und Applogs.

Empfehlung: einen Teil der Observability auf den Resolver verlagern (strukturierte Logs, Metriken, Traces) statt nur auf Paketebene zu arbeiten.

4. Reifere Implementierungen auf der Serverseite

Große Open-Source- (und kommerzielle) rekursive Resolver liefern inzwischen stabile DoT-Implementierungen, oft DoH und zunehmend DoQ. Dadurch kann man:

einen internen oder Split-Horizon-Resolver betreiben, der mehrere Transporte annimmt (UDP/TCP 53, DoT, optional DoH/DoQ);
trennen, wie Clients sich verbinden, von der Art, wie autoritative Server befragt werden;
Clients schrittweise umstellen, ohne die Gesamt-DNS-Architektur zu brechen.

Kurzer Vergleich DoT / DoH3 / DoQ

Eine kompakte Übersicht zur Einordnung der drei Transporte.

Protokoll	Unterliegender Transport	Typischer Port	Multiplexing	Im Webtraffic versteckt	Typische Einsatzfälle
DoT	TLS über TCP	853/TCP	Begrenzt auf einen TCP-Flow	Nein	Basis für verschlüsseltes DNS zwischen Clients/Forwardern und Unternehmens- oder Public-Resolvern
DoH3	HTTP/3 (QUIC) über UDP	443/UDP	Ja, via HTTP/3	Ja (schwer von HTTPS zu unterscheiden)	Browser, Apps, die in bestehende HTTP-Stacks eingebettet werden sollen
DoQ	QUIC nativ über UDP	853/UDP	Ja, QUIC-Multiplexing	Nein (wirkt wie generisches QUIC)	Moderne rekursive Resolver; Latenz- und resilienzsensitiver Betrieb

Wichtig: Keines dieser Protokolle ersetzt DNSSEC (das die Datenintegrität zwischen Resolvern und Autoritäten schützt); sie ergänzen es, indem sie Vertraulichkeit und Integrität des Transports zwischen Client und Resolver sichern.

Architektureinflüsse auf deine DNS-Infrastruktur

Verschlüsselte DNS-Flüsse zwischen Client, Unternehmens-Resolver und öffentlichen Resolvern

Das Diagramm zeigt eine typische Architektur Ende 2025:

Links besitzt der Client (Endgerät, Mobilgerät, Server) einen Stub-Resolver, der klassisches DNS (UDP/TCP 53), DoT, DoH3 oder DoQ sprechen kann.
In der Mitte terminieren ein oder mehrere Unternehmens-Resolver diese Transporte und wenden Cache, Split-Horizon und Filterung an.
Rechts werden öffentliche Resolver und authoritative Server je nach Policy über klassisches DNS oder verschlüsseltes DNS erreicht.

Die Schlüsselfrage lautet: Welche Client → Unternehmens-Resolver → öffentliche Resolver-Flüsse sind erlaubt, verschlüsselt und beobachtbar?

Öffentliche Resolver vs. Unternehmens-Resolver

Ende 2025 ist es üblich, dass ein Endgerät:

den internen Unternehmens-Resolver über UDP/TCP 53 oder DoT nutzt;
parallel einen oder mehrere öffentliche Resolver über DoH3 oder DoQ via spezifische Apps (Browser, Security-Agent, VPN-Client) befragt.

Architekturentscheidungen:

Müssen Endgeräte verpflichtend die Unternehmens-Resolver für alle Auflösungen nutzen?
Stellen Unternehmens-Resolver DoT und/oder DoQ für interne Clients bereit?
Sind DoH/DoH3-Flüsse zu öffentlichen Resolvern erlaubt, blockiert oder umgeleitet (Proxy, kontrollierte TLS-Interzeption)?

Anycast, CDN und Geolokalisierung

Mit verschlüsseltem DNS setzen große öffentliche Resolver massiv Anycast ein und verteilen QUIC/TLS-Verbindungen je nach Standort des Clients. Das kann führen zu:

unterschiedlichen Auflösungen (verschiedene CDN-Einstiegspunkte je nach vom Resolver gesehener Quell-IP);
Differenzen zwischen einem Client über DoH3/DoQ und einem anderen über UDP 53 zu einem anderen Resolver;
Nebeneffekten, wenn ein Proxy oder VPN die Quell-IP verändert.

Für latenz- oder geosensitive Anwendungen (Video, Gaming, kritische APIs) kann es sinnvoll sein, klar zu dokumentieren, welcher Resolver erwartet wird und welcher Transport empfohlen ist.

Observability, Logs und Compliance

In einer Welt, in der DNS standardmäßig verschlüsselt ist, gilt als Best Practice:

Logs auf Resolver-Ebene zu zentralisieren (Abfragen, Antworten, Fehlercodes, Auflösungszeiten);
Metriken (Prometheus, OpenTelemetry, etc.) bereitzustellen, um Latenz, Fehler und Volumina pro Transport (UDP, DoT, DoH3, DoQ) zu verfolgen;
festzulegen, was geloggt wird, um DSGVO und interne Datenschutzrichtlinien einzuhalten.

Kurz: Statt „Port 53 zu sniffen“ solltest du deine Resolver ausstatten.

Sicherheit und Zugriffskontrolle

Sicherheitskontrollen müssen neu gedacht werden:

Egress-Filtering: Welche Ports/Hosts sind erlaubt für DoT (853), DoQ (853/UDP), DoH3 (443/QUIC)?
Segmentierung: Welche Netzsegmente dürfen zu öffentlichen Resolvern, welche müssen zwingend über einen internen Resolver gehen?
Detection: Wie erkennt man ein Endgerät, das unerlaubtes verschlüsseltes DNS direkt ins Internet schickt?

Ein robustes Design kombiniert typischerweise:

einen oder mehrere interne Resolver, die mindestens DoT anbieten;
klare (und durchgesetzte) Richtlinien für ausgehende verschlüsselte DNS-Flüsse;
regelmäßiges Monitoring von „Off-Policy“-Auflösungsversuchen.

Technische Checkliste Ende 2025

Diese Checkliste hilft, die Bereitschaft schnell einzuschätzen.

Schicht	Kontrollpunkt	Frage, die man sich stellen sollte
Interner Resolver	DoT-Support (ggf. DoQ)	Bieten meine internen Resolver mindestens DoT für Clients an?
Firewall / Proxy	Policy zu 53/853/443	Habe ich explizite Regeln für verschlüsseltes DNS (DoT, DoH3, DoQ) und nicht nur für UDP/TCP 53?
Endgeräte	DNS-Konfiguration	Wer steuert die DNS-Einstellungen von OS und Browsern (GPO, MDM, Skripte etc.)?
Observability	DNS-Logs und -Metriken	Kann ich einen App-Ausfall mit verschlüsselten DNS-Metriken (Latenz, Timeouts, Fehler) korrelieren?
Compliance	Nachvollziehbarkeit	Habe ich eine klare Antwort auf „Wer hat was wann über welchen Resolver aufgelöst?“ unter Wahrung der Vertraulichkeit?

Die Vergleichstabelle lässt sich auch als CSV herunterladen (siehe Download-Block), um sie in eigenen Dashboards oder internen Unterlagen zu nutzen.

Empfohlener Aktionsplan für Infra-Teams

Ist-Aufnahme erstellen
- Welche Resolver werden genutzt (intern, extern)?
- Welche Transporte laufen schon produktiv (UDP/TCP 53, DoT, DoH, VPN-Tunnel etc.)?
Klare Zielarchitektur definieren
- DoT als Pflicht-Basis zwischen Endgeräten und internen Resolvern.
- DoH3 und/oder DoQ gezielt aktiviert je nach Use Case (Mobilität, Performance, App-Anforderungen).
Resolver aktualisieren
- Zuerst DoT aktivieren, mit sauber gemanagten Zertifikaten.
- DoQ in einer Pilotumgebung bewerten (Latenz, Stabilität, Observability).
Netzfilterung anpassen
- Eine Policy für ausgehende verschlüsselte DNS-Flüsse formulieren.
- Ausnahmen dokumentieren (DNS-Relay eines Partners, Remote-Standort, Security-Agent).
Observability aufsetzen
- DNS-Logs auf Resolver-Ebene zentralisieren.
- Volumina und Latenz pro Transport (UDP, DoT, DoH3, DoQ) verfolgen.
Mit App-Teams kommunizieren
- Änderungen erklären (neue Ports, neue Resolver, mögliches Browser-Verhalten).
- Best Practices für die Resolver-Wahl in Anwendungen dokumentieren.
Regelmäßig testen
- Skripte oder Monitoring-Jobs, die Auflösung über jeden Transport (UDP, DoT, DoH3, DoQ) zu den Schlüssel-Resolvern prüfen.
- Unterschiede bei Latenz und Verhalten (Timeouts, sporadische Fehler) analysieren.

FAQ

Muss ich alles auf DoQ umstellen und DoT aufgeben?

Nein. DoQ ersetzt DoT nicht abrupt, sondern ergänzt es. In der Praxis bleiben die meisten Architekturen Multi-Transport: UDP/TCP 53 für Kompatibilität, DoT als verschlüsselte Basis, DoH3 und/oder DoQ für gezielte Bereiche (Mobilität, Performance, App-Anforderungen).

Sind DoH3 und DoQ sicherer als DoT?

Kryptografisch stützen sich alle drei auf ähnliche Primitiven (TLS oder QUIC über TLS) und bieten vergleichbare Vertraulichkeit. Unterschiede liegen im Transport: Multiplexing, Verlustbehandlung, Tarnung im Webtraffic, Fähigkeit bestimmte Middleboxes zu passieren.

Welche Ports sollte ich auf der Firewall für diese Protokolle öffnen?

Grundsätzlich: DoT nutzt 853/TCP, DoQ 853/UDP, DoH/DoH3 Port 443 (TCP und/oder UDP je nach HTTP/2 oder HTTP/3). Die Öffnung muss überlegt sein: Wenn alle diese Ports ins Internet offen sind, können Endgeräte Unternehmens-Resolver umgehen.

Hebelt verschlüsseltes DNS mein bestehendes DNS-Filtering aus?

Ja, wenn Endgeräte direkt öffentliche Resolver über DoH3/DoT/DoQ anfragen. Deshalb braucht es eine klare Policy: Welche verschlüsselten DNS-Flüsse sind erlaubt, welche müssen zwingend über einen Unternehmens-Resolver, und wie werden Abweichungen erkannt?

Wie teste ich, ob mein Resolver DoT, DoH3 oder DoQ unterstützt?

Die meisten Implementierungen dokumentieren Beispielbefehle (kdig, drill, curl für DoH oder spezielle DoQ-Clients). Diese Tests lassen sich in Validierungsprozesse und Monitoring-Skripte einbinden, um sicherzustellen, dass jeder Transport wie erwartet funktioniert.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

Vergleich DoH3 / DoQ / DoT (CSV)

FAQ