Frage systemd-resolved

    Seit Jahren nutze ich die klassische Auflösung über die resolv.conf, also direkt über die glibc. In einem Gespräch hat mich ein Bekannter darauf aufmerksam gemacht, dass er systemd-resolved verwendet. Vor Jahren habe ich jedoch öfter gelesen, dass systemd-resolved Probleme machen kann, z.B. in Verbindung mit DNSSEC usw. Mich würde interessieren, wie der Stand heute ist: Nutzt jemand von euch systemd-resolved produktiv und wie sind die Erfahrungen in Bezug auf Stabilität und Zuverlässigkeit?

    Ja, nutze ich problemlos seit 2022. Die Themen rund um DNSSEC kamen meines Erachtens daher, dass man den systemd-resolved so einstellen konnte, dass er strikt DNSSEC forderte - was bei vielen Aufrufen zwangsläufig scheiterte. Erschwerend kam hinzu, dass einige Distributionen ihn so standardmäßig auslieferten - und dann hat sich bei vielen der Eindruck manifestiert, dass er nicht funktioniert, und dass es am DNSSEC liegt. Dabei ist es am Ende einfach nur eine Frage der korrekten Konfiguration. Ich hab heute noch "DNSSEC=allow-downgrade" drin.

    In der Standardkonfiguration von systemd-resolved ist das DNSSEC Feature deaktivieren. Das funktioniert soweit recht problemlos und auch zuverlässig. Hatte man es in der Vergangenheit aktiviert, dann war das genau der Punkt, der wohl am meisten Probleme gemacht hat. Und vor allem dann, wenn man die wie von frank_m angesprochene "allow-downgrade" Option gesetzt hatte. Die hatte nämlich oft nicht ganz so zuverlässig funktioniert wie man sich das gedacht hatte (siehe z.B. hier https://github.com/systemd/systemd/issues/32570). Mittlerweile sollten aber auch da diesbezüglich die meisten Bugs (oder sogar alle) behoben sein.

    Ich nutze hier systemd-resolved schon recht lange. Das primär wegen 2 Funktionen, die der normale Resolver nicht kann:

    1. Cache

    2. Split DNS (vor allem in Verbindung mit einem VPN)

    Zitat von Paul

    Die hatte nämlich oft nicht ganz so zuverlässig funktioniert wie man sich das gedacht hatte (siehe z.B. hier https://github.com/systemd/systemd/issues/32570). Mittlerweile sollten aber auch da diesbezüglich die meisten Bugs (oder sogar alle) behoben sein.

    Gut zu wissen.


    Zitat von frank_m

    Dabei ist es am Ende einfach nur eine Frage der korrekten Konfiguration. Ich hab heute noch "DNSSEC=allow-downgrade" drin.

    Die richtige Config bringt natürlich nichts, wenn die Software Bugs hat - und wenn man die Software dadurch weit vor 2024 abschreibt.

    Ich danke euch erst mal für eure Einschätzungen. So wie ich das in der Doku gelesen habe, würden für mich die Vorteile beim Cache und bei der flexibleren Behandlung der Nameserver-Reihenfolge liegen. Gerade wenn ein oder zwei Nameserver nicht erreichbar sind, kommt es mit der klassischen resolv.conf schnell zu "Verzögerungen", was resolved deutlich besser löst. DNSSEC möchte ich nicht direkt durch systemd-resolved validieren lassen, sondern weiterhin meinen eigenen DNS-Servern überlassen. Das müsste doch so möglich sein.

    Zitat von Hille

    Das müsste doch so möglich sein.

    Ja, das sollte funktionieren. Ich war mir eben selbst unsicher, ob DNSSEC trotzdem vom Resolver validiert wird, auch wenn ein Client das nicht explizit anfragt. Aber das scheint dennoch der Fall zu sein, wenn der Resolver das aktiviert hat.

    Mit welchem OS setzt Ihr denn den systemd-resolved ein?

    Ich habe zwei Rocky Linux 8 Server im Betrieb, einen aus 2024 ohne systemd-resolved und einen aus 2025 mit systemd-resolved.

    Lt. Red Hat ist der Einsatz von systemd-resolved selbst bei RHEL 9 noch ein "Technology Preview" und nicht für den Produktiveinsatz empfohlen, siehe https://docs.redhat.com/en/documentati…ging-networking

    Offenbar muss netcup am Image von Rocky Linux 8 etwas geändert haben, denn das originale Rocky Linux 8 Image wird auch heute noch ohne systemd-resolved ausgeliefert. Leider war meine Rückfrage diesbezüglich nicht wirklich erfolgreich.

    Die Konfiguration beinhaltet u.a. folgende Parameter:

    Code
    DNSSEC=false
DNSOverTLS=no

    Die Konfiguration könnte sicherlich auch noch verbessert werden.

    Das System läuft bislang anstandslos, lediglich bei Konfigurationsarbeiten ist uns aufgefallen, dass die beiden Server unterschiedlich konfiguriert sind.