systemd-resolved.service, systemd-resolved - Verwalter für
die Auflösung von Netznamen
ÜBERSICHT
systemd-resolved.service
/lib/systemd/systemd-resolved
systemd-resolved ist ein Systemdienst, der
Netzwerknamensauflösung für lokale Anwendungen anbietet. Er
implementiert einen zwischenspeichernden und prüfenden
DNS/DNSSEC-Stub-Resolver sowie einen LLMNR- und MulticastDNS-Resolver und
-Beantworter. Lokale Anwendungen können
Netzwerknamensauflösungsanfragen über drei Schnittstellen
einreichen:
•systemd-resolved legt das native,
vollfunktionale API auf dem Bus offen. Siehe die API-Dokumentation[1]
für Details. Die Verwendung dieser API wird Clients im allgemeinen
empfohlen, da sie asynchron und vollfunktional ist (sie liefert beispielsweise
DNSSEC-Überprüfungsstatus und Schnittstellengeltungsbereiche,
wie dies für die Unterstützung link-lokaler Vernetzung notwendig
ist).
•Das Glibc
getaddrinfo(3)-ABI wie in
RFC3493[2] definiert sowie verwandte Resolver-Funktionen,
einschließlich
gethostbyname(3). Das API wird breit
unterstützt, auch über die Linux-Plattform hinaus. In seiner
aktuellen Form legt es allerdings
DNSSEC-Überprüfungsstatusinformationen nicht offen und ist nur
synchron. Diesem API unterliegt der Glibc Name Service Switch (
nss(5)).
Die Verwendung des Glibc-NSS-Moduls
nss-resolve(8) wird
benötigt, um den NSS-Resolverfunktionen von Glibc zu erlauben,
Rechnernamen mittels
systemd-resolved aufzulösen.
•Zusätzlich stellt systemd-resolved
einen lokalen DNS-Stub bereit, der auf der IP-Adresse 127.0.0.53 auf der
lokalen Loopback-Schnittstelle auf Anfragen wartet. Programme, die
DNS-Anfragen direkt stellen und sämtliche API umgehen, können
auf diesen Stub gerichtet werden, um sie mit systemd-resolved zu
verbinden. Beachten Sie, dass nachdrücklich empfohlen wird, dass lokale
Programme stattdessen das Glibc-NSS oder die Bus-API (wie oben beschrieben)
verwenden, da verschiedene Netzwerk-Auflösungskonzepte (wie linklokale
Adressierung oder LLMNR-Unicode-Domains) nicht auf das unicast DNS-Protokoll
abgebildet werden können.
Die kontaktierten DNS-Server werden aus den globalen Einstellungen
in /etc/systemd/resolved.conf, den linkabhängigen statischen
Einstellungen in Dateien /etc/systemd/network/*.network (falls
systemd-networkd.service(8) verwandt wird), den über DHCP
empfangenen linkabhängigen dynamischen Einstellungen, mittels
resolvectl(1) erfolgten Benutzeranfragen und sämtlichen
DNS-Server-Informationen, die durch andere Systemdienste verfügbar
gemacht werden, bestimmt. Siehe resolved.conf(5) und
systemd.network(5) für Details über Systemds eigene
Konfigurationsdateien für DNS-Server. Zur Verbesserung der
Kompatibilität wird /etc/resolv.conf gelesen, um konfigurierte
System-DNS-Server zu entdecken, aber nur falls sie kein Symlink auf
/run/systemd/resolve/stub-resolv.conf, /usr/lib/systemd/resolv.conf oder
/run/systemd/resolve/resolv.conf ist (siehe unten).
systemd-resolved synthetisiert
DNS-Ressourcendatensätze (RR) für die folgenden
Fälle:
•Der lokale, konfigurierte Rechnername wird auf
alle lokal konfigurierten IP-Adressen, sortiert nach ihrem Geltungsbereich,
aufgelöst oder — falls keine konfiguriert sind — die
IPv4-Adresse 127.0.0.2 (die auf dem lokalen Loopback ist) und die IPv6-Adresse
::1 (die der lokale Rechner ist).
•Die Rechnernamen »localhost« und
»localhost.localdomain« (sowie jeder Rechnername, der auf
».localhost« oder ».localhost.localdomain« endet)
wird auf die IP-Adresse 127.0.0.1 und ::1 aufgelöst.
•Der Rechnername »_gateway« wird auf
alle aktuelle Standard-Routing-Gateway-Adressen aufgelöst, sortiert
nach ihrer Metrik. Dies weist dem aktuellen Gateway einen stabilen
Rechnernamen zu. Dies ist nützlich, um es unabhängig vom
aktuellen Netzwerkkonfigurationsstatus zu referenzieren.
•Die in /etc/hosts definierte Abbildungen werden
zu ihren konfigurierten Adressen und zurück aufgelöst, sie
werden aber nicht Auflösungen für Nichtadresstypen (wie MX)
beeinflussen.
Auflösungsanfragen werden an die verfügbaren
DNS-Server und LLMNR- und MulticastDNS-Schnittstellen gemäß
der folgenden Regeln weitergeleitet:
•Auflösungen für den besonderen
Rechnernamen »localhost« werden niemals zum Netz weitergeleitet.
(Ein paar andere, besondere Rechnernamen werden auf die gleiche Art
behandelt.)
•Single-label names are routed to all local
interfaces capable of IP multicasting, using the LLMNR protocol. Lookups for
IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses
are only sent via LLMNR on IPv6. Lookups for the locally configured host name
and the "_gateway" host name are never routed to LLMNR.
•Multi-label names with the domain suffix
".local" are routed to all local interfaces capable of IP
multicasting, using the MulticastDNS protocol. As with LLMNR IPv4 address
lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6.
•Other multi-label names are routed to all local
interfaces that have a DNS server configured, plus the globally configured DNS
server if there is one. Address lookups from the link-local address range are
never routed to DNS. Note that by default lookups for domains with the
".local" suffix are not routed to DNS servers, unless the domain is
specified explicitly as routing or search domain for the DNS server and
interface. This means that on networks where the ".local" domain is
defined in a site-specific DNS server, explicit search or routing domains need
to be configured to make lookups within this DNS domain work. Note that today
it's generally recommended to avoid defining ".local" in a DNS
server, as RFC6762[3] reserves this domain for exclusive MulticastDNS
use.
Falls Nachschlagungen über mehrere Schnittstellen geroutet
werden, wird die erste erfolgreiche Antwort zurückgeliefert (und
damit die Nachschlagezonen auf allen passenden Schnittstellen effektiv
zusammengeführt). Falls die Nachschlagung auf allen Schnittstellen
fehlschlug, wird die letzte fehlgeschlagene Antwort
zurückgeliefert.
Routing of lookups may be influenced by configuring per-interface
domain names and other settings. See systemd.network(5) and
resolvectl(1) for details. The following query routing logic applies
for unicast DNS traffic:
•If a name to look up matches (that is: is equal
to or has as suffix) any of the configured search or route-only domains of any
link (or the globally configured DNS settings), the "best matching"
search/route-only domain is determined: the matching one with the most labels.
The query is then sent to all DNS servers of any links or the globally
configured DNS servers associated with this "best matching"
search/route-only domain. (Note that more than one link might have this same
"best matching" search/route-only domain configured, in which case
the query is sent to all of them in parallel).
•Falls eine Abfrage auf keine konfigurierte
Such-/nur routebare Domain passt (weder linklokal noch global) wird sie an
alle DNS-Server, die auf Links mit gesetzter Option »DNS default
route« konfiguriert sind, sowie an alle global konfigurierten
DNS-Server versandt.
•Falls kein Link als »DNS default
route« und kein globaler DNS-Server konfiguriert ist werden die
einkompilierten Ausweich-DNS-Server verwandt.
•Andernfalls schlägt die Abfrage fehl, da
kein geeigneter DNS-Server ermittelt werden konnte.
Die Option »DNS default route« ist eine logische
Einstellung, die mit resolvectl oder in .network-Dateien konfiguriert
werden kann. Falls nicht gesetzt wird sie implizit basierend auf den
für einen Link konfigurierten DNS-Domains bestimmt: falls es
nur-routebare Domains gibt (die nicht auf »~.« passen), ist
die Vorgabe falsch, andernfalls wahr.
Effektiv bedeutet dies: Damit bevorzugt alle DNS-Anfragen, die
nicht explizit auf eine bestimmte suchbare/nur-routebare Domain, die
für einen bestimmten Link konfiguriert ist, passen, konfigurieren Sie
eine nur-routebare »~.« darauf. Dies stellt sicher, dass
andere Links für die Abfrage nicht berücksichtigt werden
(außer auch sie tragen eine solche nur-routebare Domain). Um alle
solchen DNS-Anfragen zu einem bestimmten Link zu routen, nur falls kein
anderer Link bevorzugbar ist, setzen Sie die Option »DNS default
route« für den Link auf wahr und konfigurieren Sie keine
nur-routebare Domain »~.« darauf. Um schließlich
sicherzustellen, dass ein bestimmter Link niemals irgendwelchen DNS-Verkehr,
der nicht auf seine konfigurierten Such-/nur-routebaren Domains passt,
erhält, setzen sie für ihn die Option »DNS default
route« auf falsch.
Siehe die Resolved-D-Bus-API-Dokumentation[1] für
Information über die APIs, die Systemd-resolved bereitstellt.
Es werden vier Modi beim Umgang mit /etc/resolv.conf (siehe
resolv.conf(5)) unterstützt:
•systemd-resolved verwaltet die Datei
/run/systemd/resolve/stub-resolv.conf zur Kompatibilität mit
traditionellen Linux-Programmen. Diese Datei darf ein Symlink von
/etc/resolv.conf sein. Diese Datei führt den DNS-Stub 127.0.0.53 als
einzigen DNS-Server auf. Sie enthält auch eine Liste der Such-Domains,
die im Gebrauch durch Systemd-resolved sind. Die Liste der Such-Domains wird
immer aktuell gehalten. Beachten Sie, dass
/run/systemd/resolve/stub-resolv.conf von Anwendungen nicht direkt sondern nur
durch den Symlink /etc/resolv.conf verwandt werden soll. Diese Datei kann ein
Symlink von /etc/resolv.conf sein, um alle lokalen Clients, die das DNS-API
umgehen, mit systemd-resolved mit korrekten Such-Domain-Einstellungen
zu verbinden. Dieser Betriebsmodus wird empfohlen.
•Eine statische Datei /usr/lib/systemd/resolv.conf
wird bereitgestellt, die den DNS-Stub 127.0.0.53 (siehe oben) als einzigen
DNS-Server aufführt. Diese Datei kann ein Symlink von /etc/resolv.conf
sein, um alle lokalen Clients, die das lokale DNS-API umgehen, mit
systemd-resolved zu verbinden. Diese Datei enthält keine
Such-Domains.
•systemd-resolved verwaltet die Datei
/run/systemd/resolve/stub-resolv.conf zur Kompatibilität mit
traditionellen Linux-Programmen. Diese Datei darf ein Symlink von
/etc/resolv.conf sein und wird immer aktuell gehalten. Sie enthält alle
bekannten DNS-Server. Beachten Sie die Beschränkungen des Dateiformats:
es kennt kein Konzept schnittstellenbezogenener DNS-Server und enthält
daher nur systemweite DNS-Server-Definitionen. Beachten Sie, dass
/run/systemd/resolve/stub-resolv.conf von Anwendungen nicht direkt sondern nur
durch den Symlink /etc/resolv.conf verwandt werden soll. Falls dieser
Betriebsmodus verwandt wird, werden lokale Clients, die sämtliche
lokale DNS-APIs umgehen, auch systemd-resolved umgehen und direkt mit
bekannten DNS-Servern sprechen.
•Alternativ kann /etc/resolv.conf von anderen
Paketen verwaltet werden. In diesem Fall wird systemd-resolved sie
für DNS-Konfigurationsdaten auslesen. In diesem Betriebsmodus ist
systemd-resolved Konsument statt Anbieter dieser
Konfigurationsdaten.
Beachten Sie, dass der ausgewählte Arbeitsmodus für
diese Datei voll automatisch erkannt wird, abhängig davon, ob
/etc/resolv.conf ein Symlink auf /run/systemd/resolve/resolv.conf ist oder
127.0.0.53 als DNS-Server aufführt.
SIGUSR1
Beim Empfang des Prozesssignals SIGUSR1 wird
systemd-resolved die Inhalte aller von ihm verwalteten
DNS-Ressouredatensatzzwischenspeicher sowie sämtliche
Funktionsstufeninformationen, die es über konfigurierte DNS-Server
herausfand, in das Systemprotokoll ausgeben.
SIGUSR2
Beim Empfang des Prozesssignals SIGUSR2 wird
systemd-resolved die Inhalte aller von ihm verwalteten Zwischenspeicher
ausgeben. Beachten Sie, dass es normalerweise nicht notwendig sein sollte,
dies explizit anzufragen – außer zur Fehlersuche –, da
systemd-resolved sowieso jedes Mal, wenn sich die Netzwerkkonfiguration
des Rechners ändert, seine Zwischenspeicher automatisch leert. Senden
dieses Signals an systemd-resolved ist äquivalent zu dem Befehl
resolvectl --flush-caches, allerdings wird letzterer empfohlen,
da er synchron arbeitet.
SIGRTMIN+1
Beim Empfang des Prozesssignals SIGRTMIN+1 wird
systemd-resolved alles, was es über die konfigurierten
DNS-Server gelernt hat, vergessen. Insbesondere alle Informationen über
Server-Funktionalitätsunterstützung wird entfernt, und die
Ermittlungslogik für die Serverfunktionalität wird bei der
nächsten Anfrage neu gestartet, beginnend mit der am höchsten
augestatteten Funktionsstufe. Beachten Sie, dass es normalerweise nicht
notwendig sein sollte, dies explizit anzufragen – außer zur
Fehlersuche –, da systemd-resolved sowieso jedes Mal, wenn sich
die DNS-Serverkonfiguration ändert, die gelernten Informationen
vergisst. Senden dieses Signals an systemd-resolved ist
äquivalent zu dem Befehl resolvectl --reset-server-features,
allerdings wird letzterer empfohlen, da er synchron arbeitet.
- 1.
- API-Dokumentation
https://www.freedesktop.org/wiki/Software/systemd/resolved
- 2.
- RFC 3493
https://tools.ietf.org/html/rfc3493
- 3.
- RFC 6762
https://tools.ietf.org/html/rfc6762
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite
finden, schicken Sie bitte eine E-Mail an
<debian-l10n-german@lists.debian.org>.