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