Das Domain Name System (DNS) ist ein Grundpfeiler des Internets. Es übersetzt menschenlesbare Rechnernamen in IP-Adressen (und umgekehrt) und ist damit praktisch für jede Art der Netzwerkkommunikation notwendig. Somit stellt ein Client in der Regel kontinuierlich Anfragen an das DNS. Diese Anfragen laufen traditionell unverschlüsselt über das UDP-Protokoll und Port 53, was sie anfällig für unterschiedliche Arten der Manipulation macht: DNS-Spoofing oder Man-in-the-Middle-Angriffe (MITM) sind nur einige Stichwörter, die in diesem Zusammenhang immer wieder auftauchen.

In einer Zero-Trust-Architektur, die den Anspruch hat, jede Kommunikation abzusichern und grundsätzlich niemandem zu vertrauen, ist diese Art der unsicheren Netzwerkkommunikation natürlich nicht vertretbar. Das gilt unabhängig davon, ob wir externe oder interne Netzwerke betrachten. Hinzu kommt, dass immer mehr Unternehmen ihre Ressourcen in öffentliche Clouds auslagern und in einem solchen Fall eigentlich gar keine Unterscheidung mehr zwischen diesen Netzwerksegmenten möglich ist.

Durch Technologien wie DNS over HTTPS (DoH), DNS over TLS (DoT) oder DNS over QUIC (DoQ) besteht jedoch die Möglichkeit, den gesamten DNS-Datenverkehr zu verschlüsseln und ebenfalls die Authentizität der Namensserver sicherzustellen. Die beiden Technologien DoH und DoT haben wir bereits in den IT-Administrator Ausgaben 01/2019 [1] beziehungsweise 01/2024 [2] vorgestellt, weshalb wir an dieser Stelle nicht näher auf die Grundlagen dieser beiden DNS-Protokolle eingehen.

Um nun aber den Anforderungen einer Zero-Trust-Architektur zu entsprechen, ist der Support von DoH, DoT oder DoQ lediglich zur Laufzeit eines Systems nicht ausreichend. Stattdessen ist eine sichere DNS-Kommunikation bereits zum Zeitpunkt der Systeminstallation und bei jedem Start eines Systems zwingend erforderlich.

Nun ist es wichtig zu wissen, dass Anwendungen entweder direkt einen DNS-Server abfragen können oder über das POSIX-API mit dem Systemaufruf "getaddrinfo()" auf den in der Datei "/etc/resolv.conf" hinterlegten DNS-Server zurückgreifen. Das POSIX-API unterstützt jedoch keine der bereits erwähnten Technologien, um den DNS-Verkehr abzusichern und auch nicht jede Anwendung bietet Support für sichere DNS-Kommunikation an.

Um dieses Problem zu lösen, kommt auf Rechnern zumeist ein Caching-DNS-Server zum Einsatz. Dieser nimmt die Anfragen der einzelnen Anwendungen entgegen und leitet sie dann an einen externen Namensserver weiter. Die Kommunikation mit dem externen Server kann dann, je nach eingesetzter Software, auf Basis von DoH, DoT oder DoQ erfolgen.

Der hier vorgestellte Ansatz setzt auf DNS over TLS und verwendet als DNS-Caching-Server die Software unbound [3] auf einem aktuellen Fedora-Rawhide-System. Auch wenn systemd-resolved aktuell der Standard-DNS-Resolver ist, gibt es einige noch nicht gelöste Probleme, weshalb wir für diesen Workshop die aktuelle Implementierung auf Basis von unbound verwenden. In Zukunft dürften sicherlich weitere DNS-Resolver wie beispielsweise systemd-resolved Unterstützung finden.

Um die Konfiguration auch im Zusammenhang mit dem NetworkManager zu vereinfachen, setzen wir als weiteres Tool dnsconfd [4] ein. Dieses arbeitet praktisch als Vermittler zwischen dem NetworkManager und dem lokalen DNS-Resolver. Somit muss der NetworkManager nicht mehr wissen, welcher Resolver tatsächlich zum Einsatz kommt, sondern schickt stattdessen sämtliche Konfigurationsanweisungen an dnsconfd. Das Tool kümmert sich dann darum, den lokal eingesetzten Resolver entsprechend zu konfigurieren – also beispielsweise, an welche externen DNS-Server die einzelnen DNS-Anfragen weiterzuleiten sind.

Um das hier vorgestellte Setup auf Ihrem System einzurichten, installieren Sie das Paket dnsconfd und deaktivieren den standardmäßig eingesetzten DNS-Resolver systemd-resolved, sollte dieser aktiv sein:

Alle weiteren Pakete, beispielsweise der eigentliche DNS-Resolver unbound, werden automatisch durch entsprechende Abhängigkeiten installiert. An dieser Stelle sei erwähnt, dass das Beispiel auf einem aktuellen Fedora Rawhide (Version 43) basiert, sämtliche Features aber ebenfalls in den Upstream-Versionen der einzelnen Komponenten vorhanden sind.

Der Listing-Kasten zeigt ein Beispiel für eine Konfigurationsdatei des NetworkManagers. Dort definieren Sie einfach, dass sämtliche Anweisungen an das dnsconfd-Tool weiterzureichen sind und DNS-Abfragen über den lokalen Resolver unbound an die DNS-Server 9.9.9.9 und 149.112.112.112 zu senden sind. Beide IP-Adressen gehören zum datenschutzfreundlichen und malwarefilternden Anbieter Quad9. Alternativ können Sie natürlich auch Dienste wie Cloudflare (1.1.1.1) oder Google Public DNS (8.8.8.8) nutzen. Als Protokoll soll unbound hierfür DNS over TLS (DoT) verwenden. Weitere Konfigurationsoptionen für den NetworkManager finden Sie in der entsprechenden Hilfeseite des Dienstes (man NetworkManager.conf).

Falls Sie für den hinterlegten DNS-Server ein neues X.509-Zertifikat einer Certificate Authority benötigen, fügen Sie dieses einfach dem systemweiten CA-Certificate Store hinzu und starten danach den dnsconfd und NetworkManager Service einmal neu:

Ab nun sollten sämtliche DNS-Abfragen sicher mithilfe von DNS over TLS übertragen werden. Sollte es zu Problemen kommen, empfiehlt es sich, den Loglevel des DNS-Resolvers mittelsunbound-control verbosity 5 zu erhöhen und im Anschluss in den Logs der beteiligten Dienste auf Fehlersuche zu gehen:

Damit Sie nun auch schon zum Zeitpunkt des Systemstarts ein sicheres DNS verwenden können, sind einige weitere Schritte notwendig. Zuerst fügen Sie für den aktuell laufenden Linux-Kernel die DNS-Konfiguration als weiteres Kernel-Argument hinzu. Am einfachsten geht dies mit dem Tool grubby:

Im Anschluss erzeugen Sie eine neue Init-Ramdisk. Dies funktioniert mit dem Tool dracut oder im einfachsten Fall durch die erneute Installation des aktuellen laufenden Kernels:

Um ein sicheres DNS auch schon beim Rechnerstart zur Verfügung zu haben, übergeben Sie einfach die exakt gleichen Kernel-Argumente an den Anaconda-Installer. Ob Sie diese manuell oder durch eine angepasste Boot-ISO-Datei an den Installer übergeben, spielt dabei keine Rolle. Sobald Sie das System mit sicherem DNS installieren, steht Ihnen diese Funktion natürlich auch zur Laufzeit zur Verfügung. Weitere Anpassungen sind in dem Fall dann nicht mehr notwendig.

In einer Zero-Trust-Architektur ist ein sicheres, verschlüsseltes DNS zwingend erforderlich. Die Kombination der Softwarekomponenten NetworkManager, dnsconfd und unbound ermöglicht ein solches Setup und stellt bereits zum Installationszeitpunkt eines Systems ein sicheres DNS zur Verfügung.