SYSTEMD-RESOLVED.SERVICE(8)

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

ÜBERSICHT

systemd-resolved.service

/usr/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 org.freedesktop.resolve1(5) und org.freedesktop.LogControl1(5) 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[1] 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, über resolvectl(1) bereitgestellte Informationen 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. Die Unterstützung für /etc/hosts kann mit ReadEtcHosts=no deaktiviert werden, siehe resolved.conf(5).

PROTOKOLLE UND ROUTING

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

    • Namen, für die künstliche Datensätze erstellt werden (wie im vorherigen Abschnitt dargestellt), werden niemals zu dem Netzwerk geleitet und es wird sofort eine Antwort gesandt. Insbesondere bedeutet dies, dass Nachschlage-Anforderungen für »localhost« niemals ins Netzwerk geleitet werden.

    • Single-label names are routed to all local interfaces capable of IP multicasting, where LLMNR is not disabled, 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 hostname and the "_gateway" hostname are never routed to LLMNR.

    • Multi-label names with the domain suffix ".local" are routed to all local interfaces capable of IP multicasting, where MulticastDNS is not disabled, using the MulticastDNS protocol. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6.

    • Resolution of address records (A and AAAA) via unicast DNS (i.e. not LLMNR or MulticastDNS) for non-synthesized single-label names is allowed for non-top-level domains. This means that such records can be resolved when search domains are defined. For any interface which defines search domains, such look-ups are routed to that interface, suffixed with each of the search domains defined on that interface in turn. When global search domains are defined, such look-ups are routed to all interfaces, suffixed by each of the global search domains in turn. Additionally, lookup of single-label names via unicast DNS may be enabled with the ResolveUnicastSingleLabel=yes setting. The details of which servers are queried and how the final reply is chosen are described below. Note that this means that address queries for single-label names are never sent out to remote DNS servers by default, and if no search domains are defined, resolution will fail.

    • Other multi-label names are routed to all local interfaces that have a DNS server configured, plus the globally configured DNS servers if there are any. 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 these days, it's generally recommended to avoid defining ".local" in a DNS server, as RFC6762[2] reserves this domain for exclusive MulticastDNS use.

    • Address lookups are routed similarly to multi-label names, with the exception that addresses from the link-local address range are never routed to unicast DNS and are only resolved using LLMNR and MulticastDNS (when enabled).

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 (see systemd.network(5)), or the globally configured DNS settings (see the discussion of Domains= in resolved.conf(5)), "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).

    In case of single-label names, when search domains are defined, the same logic applies, except that the name is first suffixed by the search domain.

    • 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.

Effectively this means: in order to support single-label non-synthetized names, define appropriate search domains. In order to preferably route all DNS queries not explicitly matched by search/route-only domain configuration to a specific link, configure a "~." route-only domain on it. This will ensure that other links will not be considered for these queries (unless they too carry such a route-only domain). In order to route all such DNS queries to a specific link only if no other link is preferable, set the "DNS default route" option for the link to true and do not configure a "~." route-only domain on it. Finally, in order to ensure that a specific link never receives any DNS traffic not matching any of its configured search/route-only domains, set the "DNS default route" option for it to false.

Siehe die Resolved-D-Bus-API-Dokumentation[3] 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.  RFC 3493
    https://tools.ietf.org/html/rfc3493

2.  RFC 6762
    https://tools.ietf.org/html/rfc6762

3.  resolved-D-Bus-API-Dokumentation
    https://www.freedesktop.org/wiki/Software/systemd/resolved

Ü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>.