# systemd-resolved: DNS-Management im modernen Linux-Stack

TL;DR / Management Summary systemd-resolved ist der Standard-Service für die Netzwerk-Namensauflösung in modernen Ubuntu- und Debian-Systemen. Er fungiert als lokaler DNS-Caching-Proxy und Resolver. Er ersetzt die statische /etc/resolv.conf durch einen dynamischen Stub-Resolver. Wichtigste Enterprise-Features: Unterstützung für DNS-over-TLS (DoT), DNSSEC-Validierung und per-Interface DNS-Konfiguration.

# 1. Einführung & Architektur

Wie DNS heute unter der Haube funktioniert.

Früher war DNS einfach: Ein Prozess öffnete /etc/resolv.conf und fragte den ersten Server. Heute müssen wir mit VPNs, Captive Portals und flüchtigen WLANs jonglieren. systemd-resolved zentralisiert diesen Prozess.

# Der Stub-Resolver Mechanismus

systemd-resolved lauscht auf der lokalen IP 127.0.0.53 (Port 53). Die Datei /etc/resolv.conf ist heute meist nur noch ein Symlink auf /run/systemd/resolve/stub-resolv.conf.

graph TD
    A[Applikation] -->|glibc getaddrinfo| B[/etc/resolv.conf Symlink]
    B -->|Stub Resolver| C[127.0.0.53:53 systemd-resolved]
    C -->|Local Cache Check| D{Hit?}
    D -->|Yes| A
    D -->|No| E[Upstream DNS Server]
    E -->|via eth0/wlan0/vpn0| F[Internet/Company DNS]
    C -->|Optional| G[DNSSEC Validation]

# 2. Grundkonfiguration

Das Tooling beherrschen.

Das wichtigste Werkzeug ist resolvectl.

# Status prüfen

# Globaler Status und pro Interface
resolvectl status

# DNS-Server manuell setzen (temporär)

# Setze DNS für Interface enp0s1
sudo resolvectl dns enp0s1 1.1.1.1 8.8.8.8
sudo resolvectl domain enp0s1 example.com

# Permanente Konfiguration

Die globale Konfiguration erfolgt in /etc/systemd/resolved.conf.

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
MulticastDNS=yes

# 3. DNSSEC & Sicherheit

Vertrauen ist gut, Kryptografie ist besser.

DNSSEC schützt vor DNS-Spoofing und Cache-Poisoning durch kryptografische Signaturen.

# DNSSEC Modi

1. off: Keine Validierung.
2. allow-downgrade: Validiert, wenn der Upstream-Server es unterstützt. Wenn nicht, erfolgt kein Fehler (Default in vielen Distros).
3. yes: Erzwingt DNSSEC. Wenn die Signatur ungültig ist oder der Server DNSSEC nicht unterstützt, schlägt die Auflösung fehl.

# 4. Day-2 Operations: Cache & Flush

Wenn sich die IP geändert hat, aber der Server es nicht merkt.

# Cache leeren

sudo resolvectl flush-caches

# Statistiken einsehen

resolvectl statistics

Hier sehen Sie die Cache-Hit-Rate und wie viele DNSSEC-Validierungen erfolgreich waren.

# 5. Troubleshooting & “War Stories”

DNS ist immer schuld.

# Story 1: “Der resolv.conf Symlink-Fehler”

Symptom: DNS-Auflösung geht gar nicht, aber resolvectl query google.com funktioniert. Ursache: /etc/resolv.conf ist kein Symlink, sondern eine statische Datei mit falschen Einträgen, oder der Symlink zeigt ins Leere. Lösung: Symlink wiederherstellen:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# Story 2: “VPN vs. Local DNS”

Symptom: VPN ist verbunden, aber interne Firmenadressen (jira.intern.local) werden nicht aufgelöst. Ursache: systemd-resolved weiß nicht, dass .local über den VPN-Tunnel (tun0) aufgelöst werden soll. Lösung: Routing-Domain für das Interface setzen:

sudo resolvectl domain tun0 ~intern.local

Das ~ sorgt dafür, dass dieses Interface bevorzugt für diese Domain genutzt wird (Split-DNS).

# 6. Monitoring & Best Practices

• Monitoring: Prüfen Sie regelmäßig journalctl -u systemd-resolved. Suchen Sie nach “Using degraded feature set” Meldungen, die auf Probleme mit DNSSEC oder DoT hinweisen.
• DoT (DNS-over-TLS): In unsicheren Netzwerken (Cloud/Remote) sollten Sie DNSOverTLS=yes aktivieren, um DNS-Anfragen zu verschlüsseln.
• Localhost: Greifen Sie niemals direkt auf 127.0.0.53 in Ihren Applikationen zu. Nutzen Sie immer die Standard-Resolver-Libraries des OS.

# Anhang: Cheatsheet