Verschlüsseltes DNS: IETF uneins über Wege zum Finden von DoH-Servern

Das Auffinden von verschlüsselten DNS-Servern für DoH oder DoT ist derzeit noch nicht standardisiert. Die IETF ringt nun um Lösungen.

Artikel veröffentlicht am 31. Juli 2020, 12:41 Uhr, Sebastian Grüner

Die Arbeit zum Ausrollen von DoH bei der IETF wird noch einige Zeit in Anspruch nehmen. (Bild: Pixabay)

Eine Arbeitsgruppe der Internet Engineering Task Force (IETF) hat auf ihrem jüngsten virtuellen Treffen verschiedene Möglichkeiten zum Umgang mit DNS-Resolvern diskutiert, die über verschlüsselte Protokolle erreichbar sind. Denn aus der Nutzung und Verfügbarkeit von DNS über HTTPS (DoH) oder auch DNS über TLS (DoT) ergeben sich ganz praktische Probleme im Vergleich zum bisherigen klassischen DNS. Diese Probleme will die IETF nun koordiniert angehen und lösen, noch herrscht allerdings keine Einigkeit über das weitere Vorgehen.

Bei dem klassischen DNS, das unverschlüsselt über Port 53 abgewickelt wird, bekommen Endgeräte per DHCP eine IP-Adresse eines DNS-Resolvers zugewiesen, der dann zentral vom gesamten Betriebssystem genutzt wird. Für Protokolle wie eben DoH ist solch ein Vorgang jedoch noch nicht standardisiert. Hinzu kommt, dass bei DoH nun auch Anwendungen einfach und standardisiert andere DNS-Resolver nutzen können, als den im System festgelegten klassischen Resolver. Möglich ist dies etwa mit Browsern.

Die aktuelle Situation führt jedoch dazu, das Hersteller bisher verschiedene Wege gehen, um dennoch DoH-Resolver zuweisen zu können. Mozilla nutzt im Firefox für die USA etwa einen standardmäßig voreingestellten DoH-Server. Google versucht hingegen in Chrome ein Upgrade eines bestehenden DNS-Resolvers auf DoH-Servern, und pflegt dazu eine entsprechende Liste. Ähnlich will auch Microsoft für Windows vorgehen. Hinzu kommt, dass dieses Nebeneinander von Techniken in einem sogenannten Split-DNS-Szenario zu praktischen Problemen führen kann, die bisher nur manuell gelöst werden können.

Unterschiedliche Vorschläge

Mit einem Standard könnte die Zuweisung und Nutzung jedoch vereinheitlicht werden und die DNS-Zuweisung ließe sich dann wohl auch vergleichsweise problemlos automatisieren. In der Arbeitsgruppe wurden eben dazu nun verschiedene Ideen diskutiert. Ein Vorschlag sieht etwa ein eigenes Protokoll zum Auffinden von entsprechenden Resolvern vor. Dazu könnte eine Liste mit diesen vorgehalten und abgefragt werden, ähnlich wie dies bereits jetzt mit dem klassischen DNS funktioniert.

Ein weiterer Vorschlag sieht vor, dafür direkt die DNS Records zu verwenden und dort die Resolver-Adressen zu hinterlegen. Dazu sollen sogenannte designierte DNS-Resolver genutzt werden, die sich nur für bestimmte Domains zuständig zeigen. Ein Team von Google und Cloudflare schlägt vor, dass einfach jede Webseite in einem HTTP-Header ihren präferierten Server festlegt, der dann von Clients genutzt werden sollte.

Von Firmen, die sogenannte Middleboxen als Sicherheitsprodukte anbieten und damit etwa Malware-Domains oder andere Adressen filtern, kommt ebenfalls ein eigener Vorschlag. Dieser basiert auf einem Standard (Enrollment over Secure Transport), um eigene Zertifikate oder CAs an Clients im Netzwerk auszurollen. Die Technik soll nun erweitert werden, um Clients im eigenen Netz verschlüsselte DNS-Server zuzuweisen.

Ausgang ungewiss

In der Diskussion der Beteiligten herrscht derzeit noch Uneinigkeit darüber, welche der Probleme der neuen DNS-Technik denn priorisiert behandelt werden sollten und welche Vorgehensweise dafür die richtige sein könnte. Die Arbeitsgruppe will zunächst Anforderungen formulieren und möglicherweise dafür verschiedene Standards etablieren.

Offensichtlich gelöst werden muss dabei etwa ein möglicher Upgrade-Pfad des bisherigen klassischen Resolvers auf dessen verschlüsseltes Pendant, so es denn verfügbar ist, ebenso wie eine direkte Zuweisung eines Resolvers im Netzwerk. Das würde auch zumindest einen Teil des Problems mit den Split-DNS und Middleboxen lösen. Wann es dazu kommt, ist derzeit aber noch nicht abzusehen.