Provided by: manpages-de_2.14-1_all bug

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

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