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
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 der
lokalen Loopback-Schnittstelle 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 (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.
•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.
•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 ResolveUnicastSingleLabel=yes 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.
•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.
•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 RFC
6762[2] diese Domain für die exklusive MulticastDNS-Verwendung
reserviert.
•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.
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 wird durch die schnittstellenbezogenen
Routing-Domains (Such und Nur-Route) und globale Such-Domains bestimmt.
Siehe systemd.network(5) und resolvectl(1) für eine
Beschreibung, wie diese Einstellungen dynamisch gesetzt werden und der
Diskussion von Domains= in resolved.conf(5) für eine
Beschreibung von global konfigurierten DNS-Einstellungen.
Die folgende Anfrage-Routing-Logik gilt für
Unicast-DNS-Verkehr:
•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.)
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.
•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 DefaultRoute=
konfiguriert sind, sowie an alle global konfigurierten DNS-Server
versandt.
•Falls kein Link als DefaultRoute= und kein
globaler DNS-Server konfiguriert ist, wird einer der einkompilierten
Ausweich-DNS-Server verwandt.
•Andernfalls schlägt die
Unicast-DNS-Anfrage fehl, da keine geeigneten DNS-Server ermittelt werden
konnten.
Die Option DefaultRoute= 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 eine nur-routbare Domains
außer »~.« gibt, ist die Vorgabe falsch, andernfalls
wahr.
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 DefaultRoute= 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
DefaultRoute= auf falsch.
Siehe org.freedesktop.resolve1(5) für Information
über die D-Bus-APIs, die Systemd-resolved bereitstellt.
KOMPATIBILITÄT ZU DEM TRADITIONELLEN GLIBC-STUB-RESOLVER¶
Dieser Abschnitt stellt eine kurze Zusammenfassung der Unterschiede zwischen dem
in nss-resolve(8) zusammen mit systemd-resolved implementierten
Stub-Resolver und dem traditionellen, in nss-dns(8) implementierten
Stub-Resolver bereit.
•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.
•Freistehende Namen werden für A- und
AAAA-Datensätze nicht mittels Unicast-DNS aufgelöst
(außer dies wurde mit
ResolveUnicastSingleLabel= außer
Kraft gesetzt, siehe
resolved.conf(5)). Dies ist ähnlich der in
resolv.conf(5) gesetzten Option
no-tld-query.
•Such-Domains werden nicht zum
Anhängen bei mehrgliedrigen Namen benutzt. (Trotzdem werden
Such-Domains für das Routing 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 ndots 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.)
•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.
•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.
•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.
•Die in
resolv.conf(5) beschriebenen
Umgebungsvariablen
$LOCALDOMAIN und
$RES_OPTIONS werden derzeit
nicht unterstützt.
/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.
ANMERKUNGEN¶
- 1.
- RFC 3493
- 2.
- RFC 6762
Ü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>.
