DoH vs. DoT: Was DNS-Verschlüsselung schützt und was nicht

Klassisches DNS sendet Abfragen unverschlüsselt, fast immer über Port 53. RFC 7626, die Analyse der IETF zum Datenschutz bei DNS, hält fest, dass solcher Verkehr wie jeder andere von einem Lauscher eingesehen werden kann und dass ein Gegner, der die Abfragen eines Nutzers beobachtet hat, diesen Nutzer womöglich später allein anhand des Abfragemusters wiedererkennen kann, von wo aus er sich auch verbindet. DNS over TLS (DoT) und DNS over HTTPS (DoH) wurden standardisiert, um diese erste Teilstrecke zu schützen.

Welche Teilstrecke geschützt wird

Ein Lookup durchquert mehrere Teilstrecken: Der Stub-Resolver Ihres Geräts fragt einen rekursiven Resolver, der seinerseits autoritative Server fragt. RFC 7858 erklärt, dass er sich darauf konzentriert, die erste dieser Teilstrecken zu sichern, vom Stub zum rekursiven Resolver. DoH, definiert in RFC 8484, deckt dieselbe Teilstrecke ab. In den Einsatzszenarien, auf die diese RFCs zielen, schützen beide den Inhalt der Abfrage und der Antwort auf dieser Teilstrecke und nichts darüber hinaus. RFC 7858 fügt hinzu, dass nichts verhindert, das Protokoll später auch zwischen rekursiven Resolvern und autoritativen Servern anzuwenden.

DNS over TLS (RFC 7858, 2016)

DoT verpackt gewöhnliche DNS-Nachrichten in eine TLS-Sitzung über TCP. Clients und Server verwenden standardmäßig Port 853, und der RFC verbietet es, diesen Port für unverschlüsseltes DNS zu nutzen. RFC 7858 definierte zwei Nutzungsprofile: Opportunistic Privacy, bei dem der Client Verschlüsselung versucht, ohne auf der Authentifizierung des Servers zu bestehen, und Out-of-Band-Authentifizierung per Schlüssel-Pinning für Clients, die einem bestimmten Server bereits vertrauen. RFC 8310, der RFC 7858 aktualisiert, hat diese zu den Profilen Strict Privacy und Opportunistic Privacy verallgemeinert. Strict verweigert die Fortsetzung, sofern die Verbindung nicht verschlüsselt und der Server nicht authentifiziert ist. Opportunistic versucht Verschlüsselung und Authentifizierung, verlangt sie aber nicht, kann also in einer Klartextverbindung enden und schützt nur vor passiven Lauschern, nicht vor einem aktiven Angreifer auf dem Pfad.

DNS over HTTPS (RFC 8484, 2018)

DoH bildet jede DNS-Abfrage und -Antwort auf einen HTTP-Austausch ab. Ein Client sendet entweder ein GET, wobei die DNS-Nachricht base64url-kodiert und ohne Padding in einem Query-Parameter dns steht, oder ein POST mit der Nachricht als Request-Body. Server müssen beides implementieren, und der Standard-Medientyp, den jeder Client und Server unterstützen muss, ist application/dns-message. Dies ist das Beispiel des RFC selbst, eine Abfrage für www.example.com:

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

Der Wert von dns dekodiert zu derselben 33 Byte langen Abfrage im Wire-Format, die auch ein klassischer Resolver empfangen würde, Header eingeschlossen, sodass alles aus Aufbau einer DNS-Nachricht unverändert gilt. Zwei Details zielen auf das Caching: GET-Anfragen eignen sich für HTTP-Caches, und Clients sollten eine DNS-ID von 0 senden, weil eine wechselnde ID gleichwertige Abfragen getrennt cachen würde. Der RFC nennt HTTP/2 als empfohlene Mindestversion; frühere Versionen können DoH zwar transportieren, erbringen aber möglicherweise eine sehr schlechte Leistung.

Was ein Beobachter im Netzwerk sieht

Die drei Transporte nebeneinanderzustellen zeigt, was sich ändert und was nicht, aus Sicht von jemandem, der Ihre Netzwerkverbindung beobachtet, sobald eine verschlüsselte Sitzung aufgebaut ist (Strict-Modus oder Opportunistic-Modus ohne aktiven Angreifer).

Was Verschlüsselung nicht verbirgt

• Der Resolver sieht alles. DoT und DoH verlagern das Vertrauen vom Netzwerkpfad auf den Betreiber des Resolvers, und Abfragen sind beim Resolver weiterhin an Ihre Adresse gebunden. Die Wahl eines Resolvers ist eine Datenschutzentscheidung ebenso wie eine Frage der Geschwindigkeit.
• Die nächste Verbindung ist sichtbar. Nach dem Lookup verbindet sich Ihr Gerät mit der zurückgegebenen IP-Adresse, und das Netzwerk kann diese Adresse sehen. Auch der Servername ist normalerweise im Handshake der folgenden TLS-Verbindung sichtbar.
• Die Integrität der Antwort ist ein eigenes Problem. Die Transportverschlüsselung schützt die Verbindung zum Resolver. Sie beweist nicht, dass die Antwort des Resolvers dem entspricht, was der Domaininhaber veröffentlicht hat; das ist die Aufgabe von DNSSEC, behandelt in DNSSEC erklärt.
• Der Rest des Pfads liegt außerhalb des Rahmens. RFC 7858 konzentriert sich auf den Verkehr zwischen Stub und rekursivem Resolver. Wie ein Resolver anschließend autoritative Server abfragt, ist eine andere Frage.

Kompromisse für Netzwerke und Betreiber

DoT nutzt einen eigenen Port, sodass ein Netzwerk es erkennen und entscheiden kann, ob es zugelassen wird. DoH teilt sich Port 443 mit gewöhnlichem Webverkehr, wodurch es sich anhand des Ports schwerer herausgreifen lässt. RFC 8484 ist ausdrücklich, was die betriebliche Wirkung der Kanalverschlüsselung angeht: Filter- und Inspektionssysteme, die auf ungesichertem DNS-Transport beruhen, funktionieren in einer DoH-Umgebung nicht, und die Wahl des DNS-Servers durch einen Client kann die Antworten verändern, die er erhält, zum Beispiel bei Split-DNS. Ein Netzwerk, das für Filterung oder interne Namen auf seinen eigenen Resolver angewiesen ist, muss wissen, welche Anwendungen einen eigenen Resolver mitbringen.

Auch die Performance ändert sich. Beide Transporte brauchen vor der ersten Abfrage einen TCP- und TLS-Handshake, daher kommt es auf die Wiederverwendung von Verbindungen an; RFC 7858 empfiehlt Clients, eine bestehende Verbindung wiederzuverwenden, statt pro Abfrage eine neue zu öffnen. Ein dritter Transport, DNS über dedizierte QUIC-Verbindungen, wurde 2022 als RFC 9250 veröffentlicht. Er bietet ähnliche Verschlüsselungseigenschaften wie TLS, vermeidet aber das Head-of-Line-Blocking von TCP und verwendet UDP-Port 853.

Was das für Abfragen auf dieser Website bedeutet

Die Tools auf dieser Website lösen Namen auf dem Server auf, daher ändert die Einstellung für verschlüsseltes DNS auf Ihrem eigenen Gerät nichts an dem, was sie melden. Um zu sehen, was Ihre Geräte tun, suchen Sie unter Android nach der Einstellung „Privates DNS“, die DoT verwendet, und nach den Secure-DNS-Optionen in Browsern wie Chrome und Firefox, die DoH verwenden.

Quellen und weiterführende Literatur

• RFC 7626: DNS Privacy Considerations (Bortzmeyer, 2015)
• RFC 7858: Specification for DNS over Transport Layer Security (TLS) (Hu et al., 2016)
• RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS (Dickinson, Gillmor and Reddy, 2018)
• RFC 8484: DNS Queries over HTTPS (DoH) (Hoffman and McManus, 2018)
• RFC 9250: DNS over Dedicated QUIC Connections (Huitema, Dickinson and Mankin, 2022)