Ein in der Praxis etabliertes Verfahren zur DNS-Verschlüsselung ist DNS-over-HTTPS (DoH) [1]. Dieser aus dem Jahr 2018 stammende Standard verschlüsselt den DNS-Verkehr innerhalb des HTTPS-Protokolls. Somit verwendet der DNS-Traffic den gleichen Netzwerkport (TCP/443) wie HTTPS. Dies hat zur Folge, dass Administratoren erst einmal keine Möglichkeit haben, zwischen DNS- und HTTPS-Verkehr zu unterscheiden. Der Standard wird mittlerweile von den meisten Webbrowsern wie auch Windows 11 unterstützt und es gibt eine Reihe von öffentlichen DNS-Servern, die dieses Protokoll ebenfalls sprechen [2].

DNS-over-TLS (DoT) wurde bereits zwei Jahre zuvor im RfC-7858 [3] standardisiert. Wie der Name vermuten lässt, findet die Verschlüsselung des DNS-Verkehrs direkt oberhalb des User Datagram Protocols (UDP) statt, ohne dass hierfür ein weiteres Protokoll auf Applikationsebene notwendig ist. Somit fällt es DNS-Anbietern leichter, diesen Standard zu unterstützen, da nicht noch das recht komplexe HTTP-Protokoll innerhalb des DNS-Servers zu implementieren ist. Wie auch bei HTTPS ist aber auch hier eine Public-Key-Infrastruktur (PKI) notwendig, da der DNS-Server ein X.509-Zertifikat anbieten muss, sobald ein Client eine Verbindung mittels DNS-over-TLS zu einem Server herstellt, der diesen Standard unterstützt.

DoT verwendet einen dedizierten Netzwerkport (TCP/853), sodass es Administratoren im Gegensatz zu DoH möglich ist, DNS-Verkehr innerhalb des Netzwerks zu identifizieren und gegebenenfalls zu filtern, sollte dies notwendig sein.

Mit dem DNS-Utility dig können Sie ganz einfach eine manuelle Abfrage an einen rekursiven DNS-Server stellen. Dieser kümmert sich dann darum, eine Antwort auf die Anfrage zu liefern, indem beginnend bei den DNS-Root-Servern die Anfrage beim letztlich für die erfragte Domäne zuständigen DNS-Server landet. Damit die Anfrage dabei mittels TLS gesichert wird, können Sie beim Aufruf von dig die Option "+tls-ca" verwenden. In unserem Beispiel greifen wir auf den öffentlichen DNS-Server (1.1.1.1) des Anbieters Cloudflare zurück [4]. Dieser unterstützt neben regulärem DNS auf Port 53 ebenfalls die Protokolle DNS-over-HTTPS und DNS-over-TLS. So wird beispielsweise die DNS-Abfrage für "it-administrator.de" nach 88.198.228.86 aufgelöst. In den Zusatzinformationen ist ebenfalls zu erkennen, dass die Abfrage durch einen TLS-Kanal stattgefunden hat.

Durch den Einsatz der Option "+tls-ca" stellen Sie außerdem sicher, dass der Hostname des DNS-Servers mit dem Subject-Alternative-Name des X.509-Zertifikats des Servers abgeglichen wird. Somit schützen Sie sich vor Adversary-in-the-Middle-Angriffen (AITM). Solle der Hostname nicht identisch sein, schlägt der TLS-Handshake fehl. Sie können diesen Fall ganz einfach simulieren, indem Sie bei der DNS-Abfrage mittels dig die Option "+tls-hostname" verwenden und dort einen Hostnamen verwenden, der nicht dem Hostnamen des DNS-Servers entspricht.

Um die Zertifikatskette zu verifizieren, greift dig entweder auf die Zertifikatsdatei zurück, die Sie im PEM-Format mithilfe der Option "+tls-ca" an "dig" übergeben, oder aber, sollten Sie keine Datei angegeben haben, über den Standard-Zertifikatsspeicher Ihres Systems. Wo sich dieser befindet, bekommen Sie beim Einsatz von openssl recht leicht mit dem folgenden Befehl heraus:

Auf einem Fedora-System befindet sich in diesem Verzeichnis eine Datei "cert. pem", die eine Reihe an Root-CA-Zertifikaten zur Validierung von X.509-Zertifikaten enthält. In diesem Fall ist der Aufruf der dig Option "+tls-ca" also identisch mit "+tls-ca=/etc/pli/tls/cert.pem". Sollte dig das Zertifikat aufgrund von fehlenden Root-CA-Zertifikaten nicht validieren können, schlägt auch in diesem Fall die Abfrage fehl:

Das Tool kdig aus dem knot-utils-Paket des DNS-Servers knot [5] erlaubt es außerdem, die Zertifikatskette des DNS-Server komplett anzuzeigen. Dies kann bei der Fehlersuche hilfreich sein, wenn es Probleme mit dem TLS-Handshake gibt. Rufen Sie das Tool dafür im Debug-Mode auf, so wie in Bild 1 zu sehen.

Um nun auch den Applikationen auf Ihrem System die Möglichkeit zu geben, DNS-Abfragen mittels DNS-over-TLS an einen rekursiven DNS-Server zu senden, können Sie einen lokalen Resolver einsetzen, der diesen Standard unterstützt. Wir verwenden hierfür "systemd-resolved", der schon einmal Thema in IT-Administrator 01/2021 [6] war.

Bild 2 zeigt ein Beispiel, wie Sie systemd-resolved auf einer bestimmten Schnittstelle für TLS-over-DNS konfigurieren. Denken Sie auch daran, den DNS-Server im Format "IP#Server-Name" anzugeben, da hiermit die TLS-Erweiterung Server Name Indication (SNI) aktiviert wird, um das X.509-Zertifikat des DNS-Servers zu validieren. Sollte der DNS-Server jedoch kein DoT unterstützen, schlagen sämtliche Abfragen fehl. In einem solchen Fall können Sie den DNS-over-TLS "opportunistic"-Modus verwenden, jedoch ist systemd-resolved dann nicht in der Lage, die Authentizität des Servers zu verifizieren. Das schützt dann zwar vor passiven Lauschern im Netzwerk, nicht jedoch vor aktiven Angreifern, die den DNS-Verkehr manipulieren.

Möchten Sie DNS-over-TLS nicht nur auf einer einzelnen Schnittstelle aktivieren, können Sie die globalen Einstellungen für den Dienst in der Datei etc/systemd/resolved.conf" anpassen:

Im Anschluss an die Änderungen starten Sie den Dienst neu:

Der DNS-over-TLS Standard erlaubt eine verschlüsselte Kommunikation mit einem DNS-Server über einen dedizierten Netzwerkport. Die Authentizität eines Servers können Sie mithilfe des eingesetzten X.509-Zertifikats ebenfalls sicherstellen. Um auch Anwendungen auf einem System den sicheren Zugang zu einem DNS-Server zu ermöglichen, muss der lokale Resolver diesen Standard ebenfalls unterstützen.

Auf einem Linux-System bietet sich hierfür die Software systemd-resolved an, da diese bei den allermeisten gängigen Distributionen bereits im Software-Repository enthalten ist und Ihnen auch eine sehr einfache Konfiguration der Dienste ermöglicht.