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 D-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 native API systemd-resolved legt
mittels Varlink unter /run/systemd/resolve/io.systemd.Resolve das
AF_UNIX-Socket offen. Dies stellt ähnliche Funktionalität wie
die D-Bus-Schnittstelle bereit, ist aber während der gesamten Laufzeit
verfügbar, ohne einen laufenden D-Bus-Systembus-Vermittlerdienst zu
benötigen.
•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 den IP-Adressen 127.0.0.53 und
127.0.0.54 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.
Der DNS-Stub-Resolver auf 127.0.0.53 stellt den
vollständigen Funktionalitätsumfang des lokalen Resolvers
bereit, einschließlich LLMNR/MulticastDNS-Auflösung. Der
DNS-Stub-Resolver auf 127.0.0.54 stellt einen begrenzteren Resolver bereit,
der nur im »Proxy«-Modus arbeitet, d.h. er wird die meisten
DNS-Nachrichten recht unverändert an den aktuellen vorgelagerten
DNS-Server weitergeben (und zurück), abernicht versuchen, die
Nachrichten lokal zu verarbeiten und damit nicht die Gültigkeit von
DNSSEC zu überprüfen oder LLMNR/MulticastDNS anzubieten.
(Falls notwendig wird er aber auf DNS-über-TLS-Kommunikation
übersetzen.)
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.
•Der Rechnername »_outbound« wird
auf die lokalen IPv4- und IPv6-Adressen aufgelöst, die am
wahrscheinlichsten für die Kommunikation mit anderen Rechnern verwandt
werden. Dies wird bestimmt, indem vom Kernel eine Routing-Entscheidung
für die konfigurierten Vorgabe-Gateways erbeten wird und dann die
lokale IP-Adresse durch diese Entscheidung ausgewählt wird. Dieser
Rechnername ist nur verfügbar, falls es mindestens ein konfiguriertes
lokales Vorgabe-Gateway gibt. Dies weist der lokalen,
auswärtsgerichteten IP-Adresse einen stabilen Rechnernamen zu. Das ist
nützlich, um diesen Namen unabhängig vom Zustand der aktuellen
Netzwerkkonfiguration zu referenzieren.
•Der Rechnername »_localdnsstub«
wird auf die IP-Adresse 127.0.0.53 aufgelöst, d.h. die Adresse, auf der
der lokale DNS-Stub (siehe oben) auf Anfragen wartet.
•Der Rechnername »_localdnsproxy«
wird auf die IP-Adresse 127.0.0.54 aufgelöst, d.h. die Adresse, auf der
der lokale DNS-Proxy (siehe oben) auf Anfragen wartet.
•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¶
Die von systemd-resolved.service empfangenen
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 für diese Schnittstelle definierten Servern geleitet, wobei
jeder diese Such-Domains angehängt wird. Wenn globale Such-Domains
definiert sind, werden solche Abfragen an alle die globalen Server geleitet.
Für jede Such-Domain werden die Abfrage der Reihe nach durch
Anhängen der Such-Domain an den Namen durchgeführt.
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, der von systemd-resolved.service veranlasst wird:
•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 Resolver und dem traditionellen, in
nss-dns 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, falls sie in /etc/hosts bereitgestellt
würden. Beachten Sie aber, dass die Details der Zusammenstellung der
Abfrage der Steuerung der Client-Bibliothek unterliegt. nss-dns wird zuerst
versuchen, Namen mittels Such-Domains aufzulösen, und selbst wenn diese
Anfragen an systemd-resolved geleitet werden, wird dieser sie an das Netzwerk
gemäß den normalen Regeln für das Routen von
mehrgliedrigen Namen senden [3].
•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.[4]
•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.
•Der nss-dns-Resolver verwaltet nur wenig Zustand
zwischen aufeinanderfolgenden DNS-Anfragen und spricht für jede Abfrage
immer zuerst mit dem erstenin /etc/resolv.conf aufgeführten DNS-Server.
Bei Fehlschlägen fährt er mit dem nächsten fort, bis er
das Ende der Liste erreicht, wo dann die Abfrage fehlschlägt. Der
Resolver in systemd-resolved.service behält dagegen Zustand bei
und wird ständig mit dem gleichen Server für alle Abfragen
für einen bestimmten Nachschlagebereich sprechen, bis irgendeine Art
von Fehler gesehen wird. Zu diesem Zeitpunkt schaltet er zum nächsten
und bleibt dann kontinuierlich mit diesem für alle Abfragen im
Geltungsbereich bis zum nächsten Fehlschlag und so weiter. Am Ende
kehrt er zum ersten konfigurierten Server zurück. Dies erfolgt zur
Optimierung von Nachschlagezeiten, insbesondere angesichts der Tatsache, dass
der Resolver typischerweise zuerst auf den Funktionalitätsumfang eines
bestimmten Servers prüfen muss, bevor er mit ihm kommuniziert, was Zeit
kostet. Dieses geänderte Verhalten impliziert, dass aufgeführte
DNS-Server pro Nachschlagegeltungsbereich äquivalent für die
Zonen, die sie bedienen, sein müssen, so dass das Senden einer Abfrage
zu einem von ihnen das gleiche Ergebnis wie das Senden zu einem anderen
konfigurierten DNS-Server ergeben wird.
/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 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.
Hinzugefügt in Version 231.
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.
Hinzugefügt in Version 231.
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.
Hinzugefügt in Version 235.
SIGHUP
Beim Empfang des Prozesssignals
SIGHUP wird
systemd-resolved die Inhalte aller von ihm verwalteten Zwischenspeicher
rausschreiben, alle offenen TCP-Verbindungen verwerfen (falls vorhanden) und
seine Konfigurationsdateien neu laden.
Hinzugefügt in Version 256.
ZUGANGSBERECHTIGUNGEN¶
systemd-resolved unterstützt die durch
ImportCredential=/LoadCredential=/SetCredential=
implementierte Dienste-Zugangsberechtigungslogik (siehe
systemd.exec(5) für Details). Die folgenden
Zugangsberechtigungen werden verwandt, wenn sie hereingegeben werden.
network.dns, network.search_domains
Kann eine Leerzeichen-getrennte Liste von
DNS-Server-IP-Adressen und DNS-Such-Domains enthalten. Diese Information wird
nur verwandt, wenn keine explizite Konfiguration über
/etc/systemd/resolved.conf, /etc/resolv.conf oder die Kernelbefehlszeile
bereitgestellt wurde.
Hinzugefügt in Version 253.
KERNEL-BEFEHLSZEILE¶
systemd-resolved respektiert auch zwei
Kernel-Befehlszeilenoptionen:
nameserver=, domain=
Akzeptiert die IP-Adresse eines DNS-Servers (im Falle von
nameserver=) und eine DNS-Such-Domain (im Falle von
domain=).
Kann mehrfach verwandt werden, um mehrere DNS-Server/Such-Domains zu
definieren. Falls eine dieser Optionen festgelegt ist, wird /etc/resolv.conf
nicht gelesen und die Einstellungen
DNS= und
Domains= von
resolved.conf(5) werden ignoriert. Diese zwei
Kernelbefehlszeilenoptionen setzten daher die Systemkonfiguration außer
Kraft.
Hinzugefügt in Version 253.
IP-PORTS¶
Der Dienst systemd-resolved wartet auf den folgenden
IP-Ports auf Anfragen:
•Port 53 auf IPv4-Adresse 127.0.0.53 und
127.0.0.54 (beide sind auf der lokalen Loopback-Schnittstelle
»lo«). Dies ist der lokale DNS-Rumpf, wie oben beschrieben.
Sowohl UDP als auch TCP sind abgedeckt.
•Port 5353 auf allen lokalen Adressen, sowohl IPv4
als auch IPv6 (0.0.0.0 und ::0), für MulticastDNS auf UDP. Bachten Sie,
dass die eingehenden Datagramme durch die Netzwerkschnittelle beim Eintritt
gefiltert werden, obwohl das Socket an alle lokalen Schnittstellen mittels der
ausgewählten »Platzhalter«-IP-Adresse gebunden ist und
getrennte MulticastDNS link-lokale Geltungsbereiche für jeden verwaltet
werden, wobei berücksichtigt wird, ob MulticastDNS für die
Schnittstelle aktiviert ist.
•Port 5355 auf allen lokalen Adressen, sowohl IPv4
als auch IPv6 (0.0.0.0 und ::0), für LLMNR auf sowohl TCP wie auch UDP.
Wie bei MulticastDNS wird die Filterung auf eingehenden
Netzwerk-Schnittstellen durchgeführt.
ANMERKUNGEN¶
- 1.
- RFC 3493
- 2.
- RFC 6762
- 3.
- Enhält /etc/resolv.conf beispielsweise
nameserver 127.0.0.53
search foobar.com barbar.com
und wir suchen nach »localhost«, dann wird nss-dns
die folgende Anfrage an systemd-resolved, das unter 127.0.0.53:53 auf
Anfragen wartet: zuerst »localhost.foobar.com«, dann
»localhost.barbar.com« und schließlich
»localhost«. Falls die ersten zwei Abfragen (hoffentlich)
fehlschlagen, wird systemd-resolved eine Anfrage für die dritte
Anfrage synthetisieren.
Wird nss-dns mit einer Such-Domain eingesetzt, ist es
daher essenziell, immer nss-files mit einer höheren Priorität zu
konfigurieren und Abbildungen für Namen bereitzustellen, die nicht
mittels Such-Domains aufgelöst werden sollen.
- 4.
- Es gibt derzeit mehr als 1.500 Domain-Namen oberster Stufe und
regelmäßig werden neue hinzugefügt, oft mittels
»attraktiver« Namen, die wahrscheinlich auch lokal verwandt
werden. Indem mehrgliedrige Namen auf diese Art nicht nachgeschlagen
werden, wird in beide Richtungen Zerbrechlichkeit vermieden: 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
auf oberster Stufe erstellt wird oder wenn eine neue Unter-Domain einer
Domain oberster Stufe registriert wird. Durch Auflösen jedes
übergebenen Namens als entweder relativ oder absolut wird diese
Mehrdeutigkeit vermieden.
Ü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 die
Mailingliste
der Übersetzer.
