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

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, 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 allen 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 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

        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> und Mario
       Blättermann <mario.blaettermann@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@lists.debian.org>.

systemd 243                                                                          SYSTEMD-RESOLVED.SERVICE(8)