.\" -*- coding: UTF-8 -*-
'\" t
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH SYSTEMD\-RESOLVED\&.SERVICE 8 "" "systemd 247" systemd\-resolved.service
.ie  \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH BEZEICHNUNG
systemd\-resolved.service, systemd\-resolved \- Verwalter für die Auflösung von
Netzwerknamen
.SH ÜBERSICHT
.PP
systemd\-resolved\&.service
.PP
/lib/systemd/systemd\-resolved
.SH BESCHREIBUNG
.PP
\fBsystemd\-resolved\fP 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:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBsystemd\-resolved\fP legt das native, vollfunktionale API auf dem Bus
offen\&. Siehe \fBorg.freedesktop.resolve1\fP(5) und
\fBorg.freedesktop.LogControl1\fP(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)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Das Glibc \fBgetaddrinfo\fP(3)\-ABI wie in
\m[blue]\fBRFC3493\fP\m[]\&\s-2\u[1]\d\s+2 definiert sowie verwandte
Resolver\-Funktionen, einschließlich \fBgethostbyname\fP(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 (\fBnss\fP(5))\&. Die Verwendung des Glibc\-NSS\-Moduls
\fBnss\-resolve\fP(8) wird benötigt, um den NSS\-Resolverfunktionen von Glibc zu
erlauben, Rechnernamen mittels \fBsystemd\-resolved\fP aufzulösen\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Zusätzlich stellt \fBsystemd\-resolved\fP 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
\fBsystemd\-resolved\fP 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\&.
.RE
.PP
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
\fBsystemd\-networkd.service\fP(8) verwandt wird), den über DHCP empfangenen
linkabhängigen dynamischen Einstellungen, über \fBresolvectl\fP(1)
bereitgestellte Informationen und sämtlichen DNS\-Server\-Informationen, die
durch andere Systemdienste verfügbar gemacht werden, bestimmt\&. Siehe
\fBresolved.conf\fP(5) und \fBsystemd.network\fP(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)\&.
.SH "SYNTHETISCHE DATENSÄTZE"
.PP
\fBsystemd\-resolved\fP synthetisiert DNS\-Ressourcendatensätze (RR) für die
folgenden Fälle:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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 der lokalen
Loopback\-Schnittstelle ist) und die IPv6\-Adresse ::1 (die auf dem lokalen
Rechner ist), aufgelöst\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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 \fIReadEtcHosts=no\fP deaktiviert werden, siehe
\fBresolved.conf\fP(5)\&.
.RE
.SH "PROTOKOLLE UND ROUTING"
.PP
Auflösungsanfragen werden an die verfügbaren DNS\-Server und LLMNR\- und
MulticastDNS\-Schnittstellen gemäß den folgenden Regeln weitergeleitet:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Namen, für die künstliche Datensätze erstellt werden (der lokale
Rechnername, »localhost« und »localdomain«, das lokale Gateway, wie im
vorherigen Abschnitt dargestellt), und in /etc/hosts konfigurierte Adressen
werden niemals zu dem Netzwerk geleitet und es wird sofort eine Antwort
gesandt\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Freistehende Namen werden mittels LLMNR auf allen lokalen Schnittstellen
aufgelöst, auf denen LLMNR aktiviert ist\&. Abfragen für IPv4\-Adressen
werden nur mittels LLMNR auf IPv4 gesandt und Abfragen für IPv6\-Adressen
werden nur mittels LLMNR auf IPv6 gesandt\&. Beachten Sie, dass Abfragen für
freistehende synthetisierte Namen nicht an LLMNR, MulticastDNS oder unicast
DNS gesandt werden\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Anfragen für Adressdatensätze (A und AAAA) von freistehenden,
nicht\-synthetisierte Namen werden über Unicast\-DNS mittels Such\-Domains
aufgelöst. Für jede Schnittstelle, für die Such\-Domains definiert sind,
werden solche Abfragen zu dieser Schnittstelle geleitet, wobei der Reihe
nach jeder Such\-Domain auf dieser Schnittstelle daran angehängt wird\&. Wenn
globale Such\-Domains definiert sind, werden solche Abfragen an alle
Schnittstellen geleitet, wobei der Reihe nach jede der globalen Such\-Domains
angehängt wird\&. Zusätzlich kann das Abfragen von freistehenden Namen
mittels unicast DNS mit der Einstellung \fIResolveUnicastSingleLabel=yes\fP
aktiviert werden\&. Die Details, welche Server abgefragt und wie die
abschließende Antwort ausgewählt werden, ist nachfolgend
beschrieben\&. Beachten Sie, dass dies bedeutet, dass Adressabfragen für
freistehende Namen standardmäßig niemals an ferne DNS\-Server gesandt werden
und fehlschlagen werden, falls keine Such\-Domains definiert sind\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Mehrgliedrige Namen mit der Domain\-Endung »\&.local« werden mittels
MulticastDNS auf allen lokalen Schnittstellen, auf denen MulticastDNS
aktiviert ist, aufgelöst\&. Wie bei LLMNR werden IPv4\-Adressabfragen mittels
IPv4 und IPv6\-Adressabfragen mittels IPv6 gesandt\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Abfragen für mehrgliedrige Namen werden mittels Unicast\-DNS auf lokalen
Schnittstellen weitergeleitet, die einen DNS\-Server konfiguriert haben,
sowie den global konfigurierten DNS\-Servern, falls vorhanden\&. Welche
Schnittstellen verwandt werden wird durch die Routing\-Logik, basierend auf
den Such\- und Nur\-Route\-Domains, bestimmt, wie nachfolgend
beschrieben\&. Beachten Sie, dass standardmäßig Abfragen für Domains mit der
Endung »\&.local« nicht an DNS\-Server weitergeleitet werden, außer die
Domain wird explizit als Routing\- oder Such\-Domain für den DNS\-Server und
die \-Schnittstelle festgelegt\&. Das bedeutet, dass explizite Such\- und
Routing\-Domains bei Netzwerken, bei denen die Domain »\&.local« in einem
Site\-spezifischen DNS\-Server definiert ist, konfiguriert werden müssen,
damit Abfragen innerhalb dieser DNS\-Domain funktionieren\&. Beachten Sie,
dass heutzutage es im Allgemeinen empfohlen wird, die Definition von
»\&.local« in einem DNS\-Server zu vermeiden, da \m[blue]\fBRFC
6762\fP\m[]\&\s-2\u[2]\d\s+2 diese Domain für die exklusive
MulticastDNS\-Verwendung reserviert\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Adressabfragen (inverse Abfragen) werden ähnlich wie bei mehrgliedrigen
Namen weitergeleitet, außer dass Adressen von linklokalen Adressbereichen
niemals zu Unicast\-DNS weitergeleitet und nur mittels LLMNR und MulticastDNS
(falls aktiviert) aufgelöst werden\&.
.RE
.PP
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\&.
.PP
Das Routing von Abfragen wird durch die schnittstellenbezogenen
Routing\-Domains (Such und Nur\-Route) und globale Such\-Domains
bestimmt\&. Siehe \fBsystemd.network\fP(5) und \fBresolvectl\fP(1) für eine
Beschreibung, wie diese Einstellungen dynamisch gesetzt werden und der
Diskussion von \fIDomains=\fP in \fBresolved.conf\fP(5) für eine Beschreibung von
global konfigurierten DNS\-Einstellungen\&.
.PP
Die folgende Anfrage\-Routing\-Logik gilt für Unicast\-DNS\-Verkehr:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Falls ein abzufragender Name auf eine der konfigurierten
Weiterleitungs\-Domains (Such\- oder nur\-Weiterleitung) eines Links oder auf
die global konfigurierten DNS\-Einstellungen passt (das bedeutet, er ist
identisch zu oder hat eine Endung), dann wird die am »besten passende«
Weiterleitungs\-Domain bestimmt: die passende mit den meisten Anteilen\&. Die
Abfrage wird dann an alle DNS\-Server jedes Links oder dem global
konfigurierten DNS\-Server, der dieser »am besten
passenden«\-Weiterleitungs\-Domain zugeordnet ist, gesandt\. (Beachten Sie,
dass mehr als ein Link die gleiche »am besten passende«
Weiterleitungs\-Domain konfiguriert haben kann\&. In diesem Fall wird die
Anfrage parallel an alle davon gesandt\&.)
.sp
Im Falle von freistehenden Namen wird die gleiche Logik angewandt, wenn
Such\-Domains definiert sind, außer dass dem Namen der Reihe nach jede
Such\-Domain angehängt wird\&. Beachten Sie, dass diese Suchlogik auf keinen
Namen angewandt wird, der mindestens einen Punkt enthält\&. Lesen Sie auch
die Diskussion über die Kompatibilität zu dem traditionellen Glibc\-Resolver
weiter unten\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Falls eine Abfrage auf keine konfigurierte Routing\-Domain passt (weder
linklokal noch global) wird sie an alle DNS\-Server, die auf Links mit
gesetzter Option \fIDefaultRoute=\fP konfiguriert sind, sowie an alle global
konfigurierten DNS\-Server versandt\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Falls kein Link als \fIDefaultRoute=\fP und kein globaler DNS\-Server
konfiguriert ist, wird einer der einkompilierten Ausweich\-DNS\-Server
verwandt\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Andernfalls schlägt die Unicast\-DNS\-Anfrage fehl, da keine geeigneten
DNS\-Server ermittelt werden konnten\&.
.RE
.PP
Die Option \fIDefaultRoute=\fP ist eine logische Einstellung, die mit
\fBresolvectl\fP 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 eine nur\-routbare Domains
außer »~\&.« gibt, ist die Vorgabe falsch, andernfalls wahr\&.
.PP
Effektiv bedeutet dies: Um nicht künstlich erzeugte freistehende Namen zu
unterstützen, definieren Sie geeignete Such\-Domains\&. Um bevorzugt alle
DNS\-Anfragen weiterzuleiten, die nicht explizit auf eine bestimmte
Routing\-Domain, die für einen bestimmten Link konfiguriert ist, passen,
konfigurieren Sie eine nur\-routbare »~\&.« darauf\&. Dies stellt sicher,
dass andere Links für diese Abfragen nicht berücksichtigt werden (außer auch
sie tragen eine solche Routing\-Domain)\&. Um alle solchen DNS\-Anfragen zu
einem bestimmten Link zu routen, nur falls kein anderer Link bevorzugt wird,
setzen Sie die Option \fIDefaultRoute=\fP 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 Routing\-Domains passt, erhält, setzen sie
für ihn die Option \fIDefaultRoute=\fP auf falsch\&.
.PP
Siehe \fBorg.freedesktop.resolve1\fP(5) für Information über die D\-Bus\-APIs,
die Systemd\-resolved bereitstellt\&.
.SH "KOMPATIBILITÄT ZU DEM TRADITIONELLEN GLIBC\-STUB\-RESOLVER"
.PP
Dieser Abschnitt stellt eine kurze Zusammenfassung der Unterschiede zwischen
dem in \fBnss\-resolve\fP(8) zusammen mit \fBsystemd\-resolved\fP implementierten
Stub\-Resolver und dem traditionellen, in \fBnss\-dns\fP(8) implementierten
Stub\-Resolver bereit\&.
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Einige Namen werden immer intern aufgelöst (siehe »SYNTHETISCHE DATENSÄTZE«
oben)\&. Traditionell würden sie durch nss\-files aufgelöst und nur falls sie
in /etc/hosts bereitgestellt wurden\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Freistehende Namen werden für A\- und AAAA\-Datensätze nicht mittels
Unicast\-DNS aufgelöst (außer dies wurde mit \fIResolveUnicastSingleLabel=\fP
außer Kraft gesetzt, siehe \fBresolved.conf\fP(5))\&. Dies ist ähnlich der in
\fBresolv.conf\fP(5) gesetzten Option \fBno\-tld\-query\fP\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Such\-Domains werden nicht zum \fIAnhängen\fP bei mehrgliedrigen Namen
benutzt\&. (Trotzdem werden Such\-Domains für das \fIRouting\fP von Abfragen und
für Namen, die ursprünglich als freistehend oder mehrgliedrig festgelegt
wurden, verwandt\&.) Jeder Name, der mindestens einen Punkt enthält, wird
immer als FQDN interpretiert\&. Nss\-dns würde Namen sowohl als relative
(mittels Such\-Domains) und absolute FQDN\-Namen auflösen\&. Einige Namen
würden zuerst als relativ aufgelöst und nachdem die Anfrage fehlschlug, als
absolut, während andere Namen in der umgekehrten Reihenfolge aufgelöst
würden\&. Die Option \fIndots\fP in /etc/resolv\&.conf wurde verwandt, um zu
steuern, wie viele Punkte der Name haben muss, damit er zuerst als relativer
Name aufgelöst würde\&. Dieser Stub\-Resolver implementiert dies überhaupt
nicht: mehrgliedrige Namen werden nur als FQDNs aufgelöst\&. (Es gibt
derzeit mehr als 1500 Domain\-Namen oberster Stufe und es werden regelmäßig
neue hinzugefügt, oft auch mit »attraktiven« Namen, die wahrscheinlich auch
lokal verwandt werden\&. Indem mehrgliedrige Namen auf diese Art nicht
abgefragt werden, wird die Vorhersagbarkeit in beide Richtungen erhöht: ein
gültiger globaler Name könnte durch einen lokalen Namen verschleiert werden
und die Auflösung eines relativen lokalen Namens könnte plötzlich
fehlschlagen, wenn eine neue Domain oberster Stufe erstellt wird oder wenn
eine neue Unter\-Domain einer Domain oberster Stufe registriert wird\&. Indem
jeder übergebene Namen entweder als relativ oder absolut aufgelöst wird,
wird diese Mehrdeutigkeit vermieden\&.)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Dieser Resolver kennt das Konzept der besonderen Domain »\&.local«, die für
MulticastDNS verwandt wird, und wird keine Abfragen mit dieser Endung an
Unicast\-DNS\-Server weiterleiten, außer dies wird explizit konfiguriert,
siehe oben\&. Auch werden inverse Abfragen für linklokale Adressen nicht an
Unicast\-DNS\-Server gesandt\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Dieser Resolver liest /etc/hosts und speichert es intern zwischen\&. (Mit
anderen Worten, nss\-resolve ersetzt nss\-files zusätzlich zu
nss\-dns)\&. Einträge in /etc/hosts haben die höchste Priorität\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Dieser Resolver implementiert zusätzlich zum klassischen
Unicast\-DNS\-Protokoll auch LLMNR und MulticastDNS und wird freistehende
Namen mittels LLMNR (wenn aktiviert) und auf »\&.local« endende Namen
mittels MulticastDNS (wenn aktiviert) auflösen\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Die in \fBresolv.conf\fP(5) beschriebenen Umgebungsvariablen \fI$LOCALDOMAIN\fP
und \fI$RES_OPTIONS\fP werden derzeit nicht unterstützt\&.
.RE
.SH /ETC/RESOLV\&.CONF
.PP
Es werden vier Modi beim Umgang mit /etc/resolv\&.conf (siehe
\fBresolv.conf\fP(5)) unterstützt:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBsystemd\-resolved\fP 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 \fBsystemd\-resolved\fP mit
korrekten Such\-Domain\-Einstellungen zu verbinden\&. Dieser Betriebsmodus
wird empfohlen\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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
\fBsystemd\-resolved\fP zu verbinden\&. Diese Datei enthält keine
Such\-Domains\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBsystemd\-resolved\fP 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 \fBsystemd\-resolved\fP umgehen und
direkt mit bekannten DNS\-Servern kommunizieren\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Alternativ kann /etc/resolv\&.conf von anderen Paketen verwaltet
werden\&. In diesem Fall wird \fBsystemd\-resolved\fP sie für
DNS\-Konfigurationsdaten auslesen\&. In diesem Betriebsmodus ist
\fBsystemd\-resolved\fP Konsument statt Anbieter dieser Konfigurationsdaten\&.
.RE
.PP
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\&.
.SH SIGNALE
.PP
\fBSIGUSR1\fP
.RS 4
Beim Empfang des Prozesssignals \fBSIGUSR1\fP wird \fBsystemd\-resolved\fP die
Inhalte aller von ihm verwalteten DNS\-Ressourcedatensatzzwischenspeicher
sowie sämtliche Funktionsstufeninformationen, die es über konfigurierte
DNS\-Server herausfand, in das Systemprotokoll ausgeben\&.
.RE
.PP
\fBSIGUSR2\fP
.RS 4
Beim Empfang des Prozesssignals \fBSIGUSR2\fP wird \fBsystemd\-resolved\fP die
Inhalte aller von ihm verwalteten Zwischenspeicher ausgeben\&. Beachten Sie,
dass es normalerweise nicht notwendig sein sollte, dies explizit anzufragen
\(en außer zur Fehlersuche \(en, da \fBsystemd\-resolved\fP sowieso jedes Mal,
wenn sich die Netzwerkkonfiguration des Rechners ändert, seine
Zwischenspeicher automatisch leert\&. Senden dieses Signals an
\fBsystemd\-resolved\fP ist äquivalent zu dem Befehl \fBresolvectl flush\-caches\fP,
allerdings wird Letzterer empfohlen, da er synchron arbeitet\&.
.RE
.PP
\fBSIGRTMIN+1\fP
.RS 4
Beim Empfang des Prozesssignals \fBSIGRTMIN+1\fP wird \fBsystemd\-resolved\fP
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 \(en außer zur Fehlersuche \(en, da
\fBsystemd\-resolved\fP sowieso jedes Mal, wenn sich die DNS\-Serverkonfiguration
ändert, die gelernten Informationen vergisst\&. Senden dieses Signals an
\fBsystemd\-resolved\fP ist äquivalent zu dem Befehl \fBresolvectl
reset\-server\-features\fP, allerdings wird Letzterer empfohlen, da er synchron
arbeitet\&.
.RE
.SH "SIEHE AUCH"
.PP
\fBsystemd\fP(1), \fBresolved.conf\fP(5), \fBdnssec\-trust\-anchors.d\fP(5),
\fBnss\-resolve\fP(8), \fBresolvectl\fP(1), \fBresolv.conf\fP(5), \fBhosts\fP(5),
\fBsystemd.network\fP(5), \fBsystemd\-networkd.service\fP(8)
.SH ANMERKUNGEN
.IP " 1." 4
RFC 3493
.RS 4
\%https://tools.ietf.org/html/rfc3493
.RE
.IP " 2." 4
RFC 6762
.RS 4
\%https://tools.ietf.org/html/rfc6762
.RE

.SH Ü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
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
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 die
.MT debian-l10n-german@\:lists.\:debian.\:org
Mailingliste der Übersetzer
.ME .