Manpages

BEZEICHNUNG

systemd-resolved.service, systemd-resolved - Verwalter für die Auflösung von Netzwerknamen

ÜBERSICHT

systemd-resolved.service

/lib/systemd/systemd-resolved

BESCHREIBUNG

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 »/etc/systemd/network/*.network«-Dateien (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).

SYNTHETISCHE DATENSÄTZE

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, oder, falls keine konfiguriert sind, die IPv4-Adresse 127.0.0.2 (die auf dem lokalen Loopback ist) und die IPv6-Adresse ::1 (die auf dem lokalen Rechner ist), aufgelöst.

• Die Rechnernamen »localhost« und »localhost.localdomain« (sowie alle auf ».localhost« oder ».localhost.localdomain« endenden Rechnernamen) werden auf die IP-Adressen 127.0.0.1 und ::1 aufgelöst.

• Der Rechnername »_gateway« wird auf alle aktuellen Standard-Routing-Gateway-Adressen, sortiert nach ihrer Metrik, aufgelöst. Dies weist dem aktuellen Gateway einen stabilen Rechnernamen zu, was zur Referenzierung unabhängig von dem aktuellen Netzwerkkonfigurationszustand nützlich ist.

• Die in /etc/hosts definierten Abbildungen werden zu ihren konfigurierten Adressen und zurück aufgelöst, sie werden aber nicht Auflösungen für Typen, die keine Adressen sind (wie MX), beeinflussen.

PROTOKOLLE UND ROUTING

Auflösungsanfragen werden an die verfügbaren DNS-Server und LLMNR- und MulticastDNS-Schnittstellen gemäß den folgenden Regeln weitergeleitet:

• Auflösungen für den besonderen Rechnernamen »localhost« werden niemals zum Netzwerk 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 Abfragen über mehrere Schnittstellen geroutet werden, wird die erste erfolgreiche Antwort zurückgeliefert (und damit die Abfragezonen auf allen passenden Schnittstellen effektiv zusammengeführt). Falls die Abfrage auf allen Schnittstellen fehlschlug, wird die letzte fehlgeschlagene Antwort zurückgeliefert.

Das Routing von Abfragen kann durch schnittstellenabhängige Domain-Namen beeinflusst werden. Siehe systemd.network(5) für Details. Die folgende Abfrage-Routing-Logik ist auf Unicast-DNS-Verkehr anwendbar:

• 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 routbare 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-routbare 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-routbare Domain, die für einen bestimmten Link konfiguriert ist, passen, konfigurieren Sie eine nur-routbare »~.« darauf. Dies stellt sicher, dass andere Links für die Abfrage nicht berücksichtigt werden (außer auch sie tragen eine solche nur-routbare 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-routbare Domain »~.« darauf. Um schließlich sicherzustellen, dass ein bestimmter Link niemals irgendwelchen DNS-Verkehr, der nicht auf seine konfigurierten Such-/nur-routbaren 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.

/ETC/RESOLV.CONF

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 die 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 die 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 kommunizieren.

• 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 Betriebsmodus für diese Datei vollautomatisch 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.

SIGNALE

SIGUSR1

Beim Empfang des Prozesssignals SIGUSR1 wird systemd-resolved die Inhalte aller von ihm verwalteten DNS-Ressourcedatensatzzwischenspeicher 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 werden 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.

SIEHE AUCH

systemd(1), resolved.conf(5), dnssec-trust-anchors.d(5), nss-resolve(8), resolvectl(1), resolv.conf(5), hosts(5), systemd.network(5), systemd-networkd.service(8)

ANMERKUNGEN

https://www.freedesktop.org/wiki/Software/systemd/resolved

https://tools.ietf.org/html/rfc3493

https://tools.ietf.org/html/rfc6762

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian [AT] helgefjell.de> und Mario Blättermann <mario.blaettermann [AT] gmail.com> 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 [AT] lists.org>.