DoT (DNS over TLS)

DNS over TLS (DoT) ist ein in RFC 7858 spezifiziertes Protokoll, das die Vertraulichkeit von DNS-Abfragen schützt. Klassisches DNS überträgt alle Anfragen und Antworten im Klartext über UDP oder TCP auf Port 53 — für jeden Netzwerkteilnehmer, jeden Internetprovider und jeden Betreiber eines ungesicherten WLANs vollständig einsehbar. DoT schließt diese Lücke, indem es die DNS-Kommunikation in eine TLS-Verbindung einbettet, bevor die eigentliche Abfrage stattfindet. Das Ergebnis: ein Außenstehender sieht zwar, dass DNS-Abfragen an einen Resolver gesendet werden, nicht aber welche Domains abgefragt werden.

Das Problem: DNS als gläsernes Protokoll

Jedes Mal, wenn ein Gerät eine Domain auflöst — beim Abrufen einer Website, beim Verbinden mit einem Dienst, beim Senden einer E-Mail — sendet es eine DNS-Abfrage im Klartext an einen Resolver. Diese Abfragen sind für eine Vielzahl von Beobachtern einsehbar: Internetprovider können vollständige Nutzerprofile aus DNS-Daten erstellen, öffentliche WLAN-Betreiber können abgerufene Domains protokollieren, und Angreifer in Netzwerknähe können DNS-Antworten durch Spoofing manipulieren.

DNS-Abfragen verraten dabei deutlich mehr als nur den Besuch einer Website. Die Häufigkeit der Abfragen, die zeitliche Abfolge und die Kombination von Domains geben Rückschlüsse auf Verhalten, Gewohnheiten und genutzte Dienste — sowohl für Privatpersonen als auch für Unternehmen. Für Organisationen ist das besonders relevant: DNS-Abfragen interner Systeme können Informationen über eingesetzte Softwareprodukte, Cloud-Dienste und interne Infrastruktur preisgeben.

Funktionsweise: TLS-Handshake vor der ersten Abfrage

DoT nutzt Port 853 und arbeitet in zwei Phasen. Zunächst baut der Client eine TCP-Verbindung zum DoT-Resolver auf und führt einen vollständigen TLS-Handshake durch. Dabei wird die Identität des Resolvers über sein TLS-Zertifikat verifiziert — analog zur HTTPS-Authentifizierung im Browser. Erst nach erfolgreichem TLS-Handshake werden die eigentlichen DNS-Abfragen über den verschlüsselten Kanal gesendet. Die DNS-Abfragen selbst folgen dem gewohnten Protokollformat und bleiben inhaltlich unverändert; nur der Transportkanal unterscheidet sich von klassischem DNS.

Weil TLS eine verbindungsorientierte Technik ist, kann die Verbindung für mehrere aufeinanderfolgende Abfragen genutzt werden. Das reduziert den Overhead des TLS-Handshakes auf eine einmalige Investition pro Verbindung. In der Praxis halten Clients und Betriebssysteme die Verbindung für mehrere Sekunden bis Minuten offen, sodass der Performance-Unterschied zu unverschlüsseltem DNS für den Nutzer kaum spürbar ist.

DoT und der Betriebsmodus: Strict vs. Opportunistic

DoT kennt zwei Betriebsmodi, die unterschiedliche Sicherheitsniveaus bieten. Im Strict Mode wird ausschließlich eine TLS-geschützte Verbindung akzeptiert. Ist der konfigurierte DoT-Resolver nicht erreichbar oder weist sein Zertifikat Fehler auf, werden DNS-Abfragen verweigert statt auf unverschlüsseltes DNS zurückzufallen. Der Strict Mode ist die sicherere Wahl: Er stellt sicher, dass DNS-Abfragen niemals unverschlüsselt erfolgen. Allerdings erhöht er das Risiko von Ausfällen, wenn der Resolver temporär nicht erreichbar ist.

Im Opportunistic Mode versucht der Client zunächst eine DoT-Verbindung. Schlägt diese fehl — etwa weil ein Netzwerk Port 853 blockiert —, fällt er auf unverschlüsseltes DNS zurück. Der Opportunistic Mode verbessert die Privatsphäre, wo es möglich ist, ohne die Verfügbarkeit zu gefährden. Für Unternehmensumgebungen, in denen die Kontrolle über DNS-Resolver vollständig beim eigenen IT-Betrieb liegt, ist der Strict Mode die empfohlene Konfiguration.

DoT vs. DoH: Unterschiedliche Ansätze mit gleicher Absicht

Neben DoT gibt es mit DNS over HTTPS (DoH, RFC 8484) ein weiteres Protokoll zur Verschlüsselung von DNS-Abfragen. Beide Verfahren erreichen das gleiche Ziel — Vertraulichkeit von DNS-Anfragen —, unterscheiden sich jedoch im Ansatz und in den praktischen Auswirkungen.

Der entscheidende Unterschied liegt im verwendeten Port. DoT nutzt den dedizierten Port 853, der eindeutig DNS-Verkehr signalisiert. Netzwerkadministratoren können DoT gezielt erlauben oder blockieren und den Verkehr auf zugelassene Resolver beschränken. DoH hingegen ist über Port 443 nicht von normalem HTTPS-Traffic zu unterscheiden, was die Netzwerkkontrolle deutlich erschwert.

Für Unternehmensumgebungen ist dieser Unterschied erheblich: DoT ermöglicht eine explizite Netzwerkrichtlinie — erlaubt ist nur der Weg zum eigenen Resolver auf Port 853, alles andere wird blockiert. Bei DoH können Anwendungen und Browser die zentral verwalteten DNS-Einstellungen umgehen, indem sie direkt mit öffentlichen DoH-Resolvern kommunizieren. Aus Sicht des Netzwerkmanagements ist DoT deshalb für unternehmenskontrollierte Umgebungen der bevorzugte Ansatz.

DoT und DNSSEC: Komplementäre Schutzziele

DoT und DNSSEC werden häufig in einem Atemzug genannt, adressieren aber unterschiedliche Bedrohungen und ergänzen sich gegenseitig.

DNSSEC schützt die Integrität und Authentizität von DNS-Antworten. Es stellt sicher, dass eine DNS-Antwort tatsächlich vom autorisierten Nameserver stammt und nicht manipuliert wurde — indem es alle DNS-Records kryptografisch signiert. DNSSEC schützt jedoch nicht die Vertraulichkeit: Die Abfragen und Antworten bleiben im Klartext sichtbar.

DoT schützt die Vertraulichkeit der DNS-Kommunikation. Es verhindert, dass Dritte mitlesen können, welche Domains abgefragt werden. DoT schützt jedoch nicht vor einem böswilligen Resolver: Wenn der Resolver selbst kompromittiert ist oder gefälschte Antworten liefert, hilft die TLS-Verschlüsselung nicht weiter.

Die vollständige Absicherung von DNS erfordert deshalb beide Mechanismen: DNSSEC für die Integrität der Antworten, DoT für die Vertraulichkeit des Transports. In der Praxis empfehlen sowohl die IETF als auch das BSI den kombinierten Einsatz.

Serverunterstützung: Unbound, BIND und Knot Resolver

DoT wird von allen verbreiteten rekursiven DNS-Resolvern unterstützt. Unbound von NLnet Labs ist einer der am häufigsten genutzten DoT-fähigen Resolver und lässt sich mit wenigen Konfigurationszeilen als DoT-Server einrichten. BIND 9 (ab Version 9.17) unterstützt ebenfalls DoT nativ. Knot Resolver bietet ebenfalls vollständige DoT-Unterstützung und eignet sich besonders für Hochdurchsatzumgebungen.

Auf der Client-Seite ist Stubby (aus dem getdns-Projekt, mitentwickelt von NLnet Labs) ein weitverbreiteter DoT-Client für Betriebssysteme ohne native DoT-Unterstützung. Stubby agiert als lokaler DNS-Stub-Resolver, nimmt Abfragen auf 127.0.0.1 entgegen und leitet sie verschlüsselt an konfigurierte DoT-Resolver weiter. Das ermöglicht DoT-Unterstützung auch für ältere Systeme oder Anwendungen, die kein DoT nativ sprechen.

Öffentliche DoT-Resolver werden von mehreren Anbietern betrieben: Cloudflare unter 1.1.1.1 (Hostname: cloudflare-dns.com), Google unter 8.8.8.8 (Hostname: dns.google) und die Deutsche Telekom unter eigenem Hostnamen. Für Unternehmen mit Datenschutzanforderungen ist der Betrieb eines eigenen DoT-Resolvers im eigenen Rechenzentrum oder auf einem vertrauenswürdigen Hosting-Provider die souveräne Lösung.

Android Private DNS: DoT im Mobilbetrieb

Android 9 (Pie) führte DoT nativ in das Betriebssystem ein — unter dem Namen Private DNS. In den Netzwerkeinstellungen kann ein DoT-Resolver über seinen Hostnamen konfiguriert werden, zum Beispiel dns.example.de. Android baut dann automatisch eine DoT-Verbindung auf, sofern der Resolver erreichbar ist. Wird ein bestimmter Hostname eingetragen, arbeitet Android im Strict Mode — ist der Resolver nicht verfügbar, schlägt die DNS-Auflösung fehl. Die Standardeinstellung „Automatisch" nutzt dagegen den Opportunistic Mode: Android versucht DoT, fällt aber auf unverschlüsseltes DNS zurück, wenn Port 853 blockiert ist. Private DNS funktioniert geräteübergreifend für alle Apps und Netzwerkverbindungen — eine einfache Möglichkeit, auch mobile Unternehmensgeräte mit verschlüsseltem DNS auszustatten.

iOS und iPadOS unterstützen DoT ebenfalls, allerdings nicht über eine einfache Systemeinstellung. Stattdessen werden DoT- und DoH-Konfigurationen über sogenannte Encrypted-DNS-Profile (MDM-Konfigurationsprofile) ausgerollt — ein in unternehmensgeführten MDM-Umgebungen (Mobile Device Management) gut etablierter Ansatz.

Unternehmenseinsatz: Netzwerkrichtlinien und interne Resolver

Für Unternehmensumgebungen bietet DoT auf Port 853 einen praktischen Vorteil gegenüber DoH: Netzwerkadministratoren können klare Richtlinien durchsetzen. Durch Firewall-Regeln lässt sich sicherstellen, dass ausgehende DNS-Verbindungen ausschließlich zu den eigenen DoT-Resolvern auf Port 853 zulässig sind. Unkontrolliertes DNS über Port 53 oder DoH-Abfragen an externe Resolver lassen sich blockieren, ohne den verschlüsselten DNS-Verkehr zu unterbinden.

Diese Kontrolle ist insbesondere für Compliance-Anforderungen relevant. Wenn alle DNS-Abfragen über einen zentralen, unternehmensverwalteten Resolver laufen, kann dieser sowohl Schutzfunktionen übernehmen (DNS-Filterung, Blockierung bekannter Schaddomain-Listen wie DNSBL) als auch zu Logging-Zwecken genutzt werden — stets im Einklang mit datenschutzrechtlichen Anforderungen der DSGVO.

In der Praxis bewährt sich folgendes Architekturmuster: Ein zentraler rekursiver DoT-Resolver im internen Netz (z. B. Unbound) nimmt Abfragen von internen Clients über das normale DNS-Protokoll entgegen. Die Weiterleitung an öffentliche autoritative Nameserver erfolgt dann ausschließlich über DoT. Endgeräte benötigen keine DoT-Konfiguration; die Verschlüsselung erfolgt transparent auf dem Netzwerkperimeter.

BSI-Perspektive und regulatorische Einordnung

Das BSI empfiehlt in seinen technischen Richtlinien und dem IT-Grundschutz-Kompendium den Einsatz von verschlüsseltem DNS für alle sensiblen Netzwerkumgebungen. DNS over TLS wird dabei als eine der bevorzugten Maßnahmen zur Absicherung des DNS-Transports genannt. Im Kontext der NIS2-Richtlinie sind Organisationen verpflichtet, angemessene technische Maßnahmen zur Absicherung ihrer Netzwerkkommunikation zu treffen. Die Verwendung von unverschlüsseltem DNS für kritische Infrastrukturen und betroffene Einrichtungen wäre angesichts verfügbarer Alternativen wie DoT schwer zu rechtfertigen.

Aus DSGVO-Perspektive ist die Vertraulichkeit von DNS-Abfragen ein oft übersehener Aspekt. Wenn ein Mitarbeiter interne Systeme, Cloud-Dienste oder Kommunikationsplattformen über das Internet erreicht, können diese DNS-Abfragen dem Arbeitgeber Einblicke in das Verhalten von Nutzern geben — ein Aspekt, der im Kontext einer datenschutzkonformen IT-Infrastruktur berücksichtigt werden sollte. DoT stellt sicher, dass DNS-Abfragen ausschließlich dem autorisierten Resolver bekannt sind.

Relevanz für KMUs

Für kleine und mittelständische Unternehmen ist der Einstieg in DoT niedrigschwellig. Wer bereits einen eigenen rekursiven DNS-Resolver betreibt, kann DoT mit geringem Aufwand aktivieren. Wer keinen eigenen Resolver betreibt, kann auf den Endgeräten direkt Public-DoT-Resolver konfigurieren — Android-Geräte unterstützen dies über die Private-DNS-Einstellung ohne zusätzliche Software.

Der eigentliche Mehrwert liegt in der Kombination: DoT auf dem Transportpfad, DNSSEC für die Integrität der Antworten und interne DNS-Filterung für Schutz vor bekannten Schaddomain-Listen. Diese Kombination lässt sich auch ohne großes Budget in einem Mittelstandsnetzwerk umsetzen und liefert einen messbaren Beitrag zur Netzwerksicherheit — insbesondere in Umgebungen mit sensiblen Daten, regulatorischen Anforderungen oder Außenstandorten, die über öffentliche Netzwerke angebunden sind.