SYSTEMD-RESOLVED.SERVICE(8) systemd-resolved.service BEZEICHNUNG systemd-resolved.service, systemd-resolved - Verwalter fur die Auflosung von Netzwerknamen UBERSICHT systemd-resolved.service /usr/lib/systemd/systemd-resolved BESCHREIBUNG systemd-resolved ist ein Systemdienst, der Netzwerknamensauflosung fur lokale Anwendungen anbietet. Er implementiert einen zwischenspeichernden und prufenden DNS/DNSSEC-Stub-Resolver sowie einen LLMNR- und MulticastDNS-Resolver und -Beantworter. Lokale Anwendungen konnen Netzwerknamensauflosungsanfragen uber drei Schnittstellen einreichen: o systemd-resolved legt das native, vollfunktionale API auf dem Bus offen. Siehe org.freedesktop.resolve1(5) und org.freedesktop.LogControl1(5) fur Details. Die Verwendung dieser API wird Clients im allgemeinen empfohlen, da sie asynchron und vollfunktional ist (sie liefert beispielsweise DNSSEC-Uberprufungsstatus und Schnittstellengeltungsbereiche, wie dies fur die Unterstutzung link-lokaler Vernetzung notwendig ist). o Das Glibc getaddrinfo(3)-ABI wie in RFC3493[1] definiert sowie verwandte Resolver-Funktionen, einschliesslich gethostbyname(3). Das API wird breit unterstutzt, auch uber die Linux-Plattform hinaus. In seiner aktuellen Form legt es allerdings DNSSEC-Uberprufungsstatusinformationen 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 benotigt, um den NSS-Resolverfunktionen von Glibc zu erlauben, Rechnernamen mittels systemd-resolved aufzulosen. o Zusatzlich 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 samtliche API umgehen, konnen auf diesen Stub gerichtet werden, um sie mit systemd-resolved zu verbinden. Beachten Sie, dass nachdrucklich empfohlen wird, dass lokale Programme stattdessen das Glibc-NSS oder die Bus-API (wie oben beschrieben) verwenden, da verschiedene Netzwerk-Auflosungskonzepte (wie linklokale Adressierung oder LLMNR-Unicode-Domains) nicht auf das unicast DNS-Protokoll abgebildet werden konnen. Der DNS-Stub-Resolver auf 127.0.0.53 stellt den vollstandigen Funktionalitatsumfang des lokalen Resolvers bereit, einschliesslich LLMNR/MulticastDNS-Auflosung. 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 unverandert an den aktuellen vorgelagerten DNS-Server weitergeben (und zuruck), abernicht versuchen, die Nachrichten lokal zu verarbeiten und damit nicht die Gultigkeit von DNSSEC zu uberprufen oder LLMNR/MulticastDNS anzubieten. (Falls notwendig wird er aber auf DNS-uber-TLS-Kommunikation ubersetzen.) Die kontaktierten DNS-Server werden aus den globalen Einstellungen in /etc/systemd/resolved.conf, den linkabhangigen statischen Einstellungen in >>/etc/systemd/network/*.network<<-Dateien (falls systemd-networkd.service(8) verwandt wird), den uber DHCP empfangenen linkabhangigen dynamischen Einstellungen, uber resolvectl(1) bereitgestellte Informationen und samtlichen DNS-Server-Informationen, die durch andere Systemdienste verfugbar gemacht werden, bestimmt. Siehe resolved.conf(5) und systemd.network(5) fur Details uber Systemds eigene Konfigurationsdateien fur DNS-Server. Zur Verbesserung der Kompatibilitat 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 DATENSATZE systemd-resolved synthetisiert DNS-Ressourcendatensatze (RR) fur die folgenden Falle: o 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), aufgelost. o 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 aufgelost. o Der Rechnername >>_gateway<< wird auf alle aktuellen Standard-Routing-Gateway-Adressen, sortiert nach ihrer Metrik, aufgelost. Dies weist dem aktuellen Gateway einen stabilen Rechnernamen zu, was zur Referenzierung unabhangig von dem aktuellen Netzwerkkonfigurationszustand nutzlich ist. o Der Rechnername >>_outbound<< wird auf die lokalen IPv4- und IPv6-Adressen aufgelost, die am wahrscheinlichsten fur die Kommunikation mit anderen Rechnern verwandt werden. Dies wird bestimmt, indem vom Kernel eine Routing-Entscheidung fur die konfigurierten Vorgabe-Gateways erbeten wird und dann die lokale IP-Adresse durch diese Entscheidung ausgewahlt wird. Dieser Rechnername ist nur verfugbar, falls es mindestens ein konfiguriertes lokales Vorgabe-Gateway gibt. Dies weist der lokalen, auswartsgerichteten IP-Adresse einen stabilen Rechnernamen zu. Das ist nutzlich, um diesen Namen unabhangig vom Zustand der aktuellen Netzwerkkonfiguration zu referenzieren. o Der Rechnername >>_localdnsstub<< wird auf die IP-Adresse 127.0.0.53 aufgelost, d.h. die Adresse, auf der der lokale DNS-Stub (siehe oben) auf Anfragen wartet. o Der Rechnername >>_localdnsproxy<< wird auf die IP-Adresse 127.0.0.54 aufgelost, d.h. die Adresse, auf der der lokale DNS-Proxy (siehe oben) auf Anfragen wartet. o Die in /etc/hosts definierten Abbildungen werden zu ihren konfigurierten Adressen und zuruck aufgelost, sie werden aber nicht Auflosungen fur Typen, die keine Adressen sind (wie MX), beeinflussen. Die Unterstutzung fur /etc/hosts kann mit ReadEtcHosts=no deaktiviert werden, siehe resolved.conf(5). PROTOKOLLE UND ROUTING Die von systemd-resolved.service empfangenen Auflosungsanfragen werden an die verfugbaren DNS-Server und LLMNR- und MulticastDNS-Schnittstellen gemass den folgenden Regeln weitergeleitet: o Namen, fur die kunstliche Datensatze 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. o Freistehende Namen werden mittels LLMNR auf allen lokalen Schnittstellen aufgelost, auf denen LLMNR aktiviert ist. Abfragen fur IPv4-Adressen werden nur mittels LLMNR auf IPv4 gesandt und Abfragen fur IPv6-Adressen werden nur mittels LLMNR auf IPv6 gesandt. Beachten Sie, dass Abfragen fur freistehende synthetisierte Namen nicht an LLMNR, MulticastDNS oder unicast DNS gesandt werden. o Anfragen fur Adressdatensatze (A und AAAA) von freistehenden, nicht-synthetisierte Namen werden uber Unicast-DNS mittels Such-Domains aufgelost. Fur jede Schnittstelle, fur die Such-Domains definiert sind, werden solche Abfragen zu fur diese Schnittstelle definierten Servern geleitet, wobei jeder diese Such-Domains angehangt wird. Wenn globale Such-Domains definiert sind, werden solche Abfragen an alle die globalen Server geleitet. Fur jede Such-Domain werden die Abfrage der Reihe nach durch Anhangen der Such-Domain an den Namen durchgefuhrt. Zusatzlich kann das Abfragen von freistehenden Namen mittels unicast DNS mit der Einstellung ResolveUnicastSingleLabel=yes aktiviert werden. Die Details, welche Server abgefragt und wie die abschliessende Antwort ausgewahlt werden, ist nachfolgend beschrieben. Beachten Sie, dass dies bedeutet, dass Adressabfragen fur freistehende Namen standardmassig niemals an ferne DNS-Server gesandt werden und fehlschlagen werden, falls keine Such-Domains definiert sind. o Mehrgliedrige Namen mit der Domain-Endung >>.local<< werden mittels MulticastDNS auf allen lokalen Schnittstellen, auf denen MulticastDNS aktiviert ist, aufgelost. Wie bei LLMNR werden IPv4-Adressabfragen mittels IPv4 und IPv6-Adressabfragen mittels IPv6 gesandt. o Abfragen fur 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 standardmassig Abfragen fur Domains mit der Endung >>.local<< nicht an DNS-Server weitergeleitet werden, ausser die Domain wird explizit als Routing- oder Such-Domain fur 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 mussen, 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 fur die exklusive MulticastDNS-Verwendung reserviert. o Adressabfragen (inverse Abfragen) werden ahnlich wie bei mehrgliedrigen Namen weitergeleitet, ausser dass Adressen von linklokalen Adressbereichen niemals zu Unicast-DNS weitergeleitet und nur mittels LLMNR und MulticastDNS (falls aktiviert) aufgelost werden. Falls Abfragen uber mehrere Schnittstellen geroutet werden, wird die erste erfolgreiche Antwort zuruckgeliefert (und damit die Abfragezonen auf allen passenden Schnittstellen effektiv zusammengefuhrt). Falls die Abfrage auf allen Schnittstellen fehlschlug, wird die letzte fehlgeschlagene Antwort zuruckgeliefert. 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) fur eine Beschreibung, wie diese Einstellungen dynamisch gesetzt werden und der Diskussion von Domains= in resolved.conf(5) fur eine Beschreibung von global konfigurierten DNS-Einstellungen. Die folgende Anfrage-Routing-Logik gilt fur Unicast-DNS-Verkehr, der von systemd-resolved.service veranlasst wird: o 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, ausser dass dem Namen der Reihe nach jede Such-Domain angehangt wird. Beachten Sie, dass diese Suchlogik auf keinen Namen angewandt wird, der mindestens einen Punkt enthalt. Lesen Sie auch die Diskussion uber die Kompatibilitat zu dem traditionellen Glibc-Resolver weiter unten. o 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. o Falls kein Link als DefaultRoute= und kein globaler DNS-Server konfiguriert ist, wird einer der einkompilierten Ausweich-DNS-Server verwandt. o Andernfalls schlagt 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 fur einen Link konfigurierten DNS-Domains bestimmt: falls es eine nur-routbare Domains ausser >>~.<< gibt, ist die Vorgabe falsch, andernfalls wahr. Effektiv bedeutet dies: Um nicht kunstlich erzeugte freistehende Namen zu unterstutzen, definieren Sie geeignete Such-Domains. Um bevorzugt alle DNS-Anfragen weiterzuleiten, die nicht explizit auf eine bestimmte Routing-Domain, die fur einen bestimmten Link konfiguriert ist, passen, konfigurieren Sie eine nur-routbare >>~.<< darauf. Dies stellt sicher, dass andere Links fur diese Abfragen nicht berucksichtigt werden (ausser 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= fur den Link auf wahr und konfigurieren Sie keine nur-routbare Domain >>~.<< darauf. Um schliesslich sicherzustellen, dass ein bestimmter Link niemals irgendwelchen DNS-Verkehr, der nicht auf seine konfigurierten Routing-Domains passt, erhalt, setzen sie fur ihn die Option DefaultRoute= auf falsch. Siehe org.freedesktop.resolve1(5) fur Information uber die D-Bus-APIs, die Systemd-resolved bereitstellt. KOMPATIBILITAT 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. o Einige Namen werden immer intern aufgelost (siehe Synthetische Datensatze oben). Traditionell wurden sie durch nss-files aufgelost, falls sie in /etc/hosts bereitgestellt wurden. 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 aufzulosen, und selbst wenn diese Anfragen an systemd-resolved geleitet werden, wird dieser sie an das Netzwerk gemass den normalen Regeln fur das Routen von mehrgliedrigen Namen senden [3]. o Freistehende Namen werden fur A- und AAAA-Datensatze nicht mittels Unicast-DNS aufgelost (ausser dies wurde mit ResolveUnicastSingleLabel= ausser Kraft gesetzt, siehe resolved.conf(5)). Dies ist ahnlich der in resolv.conf(5) gesetzten Option no-tld-query. o Such-Domains werden nicht zum Anhangen bei mehrgliedrigen Namen benutzt. (Trotzdem werden Such-Domains fur das Routing von Abfragen und fur Namen, die ursprunglich als freistehend oder mehrgliedrig festgelegt wurden, verwandt.) Jeder Name, der mindestens einen Punkt enthalt, wird immer als FQDN interpretiert. Nss-dns wurde Namen sowohl als relative (mittels Such-Domains) und absolute FQDN-Namen auflosen. Einige Namen wurden zuerst als relativ aufgelost und nachdem die Anfrage fehlschlug, als absolut, wahrend andere Namen in der umgekehrten Reihenfolge aufgelost wurden. 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 aufgelost wurde. Dieser Stub-Resolver implementiert dies uberhaupt nicht: mehrgliedrige Namen werden nur als FQDNs aufgelost.[4] o Dieser Resolver kennt das Konzept der besonderen Domain >>.local<<, die fur MulticastDNS verwandt wird, und wird keine Abfragen mit dieser Endung an Unicast-DNS-Server weiterleiten, ausser dies wird explizit konfiguriert, siehe oben. Auch werden inverse Abfragen fur linklokale Adressen nicht an Unicast-DNS-Server gesandt. o Dieser Resolver liest /etc/hosts und speichert es intern zwischen. (Mit anderen Worten, nss-resolve ersetzt nss-files zusatzlich zu nss-dns). Eintrage in /etc/hosts haben die hochste Prioritat. o Dieser Resolver implementiert zusatzlich 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) auflosen. o Die in resolv.conf(5) beschriebenen Umgebungsvariablen $LOCALDOMAIN und $RES_OPTIONS werden derzeit nicht unterstutzt. o Der nss-dns-Resolver verwaltet nur wenig Zustand zwischen aufeinanderfolgenden DNS-Anfragen und spricht fur jede Abfrage immer zuerst mit dem erstenin /etc/resolv.conf aufgefuhrten DNS-Server. Bei Fehlschlagen fahrt er mit dem nachsten fort, bis er das Ende der Liste erreicht, wo dann die Abfrage fehlschlagt. Der Resolver in systemd-resolved.service behalt dagegen Zustand bei und wird standig mit dem gleichen Server fur alle Abfragen fur einen bestimmten Nachschlagebereich sprechen, bis irgendeine Art von Fehler gesehen wird. Zu diesem Zeitpunkt schaltet er zum nachsten und bleibt dann kontinuierlich mit diesem fur alle Abfragen im Geltungsbereich bis zum nachsten Fehlschlag und so weiter. Am Ende kehrt er zum ersten konfigurierten Server zuruck. Dies erfolgt zur Optimierung von Nachschlagezeiten, insbesondere angesichts der Tatsache, dass der Resolver typischerweise zuerst auf den Funktionalitatsumfang eines bestimmten Servers prufen muss, bevor er mit ihm kommuniziert, was Zeit kostet. Dieses geanderte Verhalten impliziert, dass aufgefuhrte DNS-Server pro Nachschlagegeltungsbereich aquivalent fur die Zonen, die sie bedienen, sein mussen, 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)) unterstutzt: o systemd-resolved verwaltet die Datei /run/systemd/resolve/stub-resolv.conf zur Kompatibilitat mit traditionellen Linux-Programmen. Diese Datei fuhrt den DNS-Stub 127.0.0.53 als einzigen DNS-Server auf. Sie enthalt 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. o Eine statische Datei /usr/lib/systemd/resolv.conf wird bereitgestellt, die den DNS-Stub 127.0.0.53 (siehe oben) als einzigen DNS-Server auffuhrt. 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 enthalt keine Such-Domains. o systemd-resolved verwaltet die Datei /run/systemd/resolve/stub-resolv.conf zur Kompatibilitat mit traditionellen Linux-Programmen. Diese Datei darf ein Symlink von /etc/resolv.conf sein und wird immer aktuell gehalten. Sie enthalt alle bekannten DNS-Server. Beachten Sie die Beschrankungen des Dateiformats: es kennt kein Konzept schnittstellenbezogenener DNS-Server und enthalt 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 samtliche lokale DNS-APIs umgehen, auch systemd-resolved umgehen und direkt mit bekannten DNS-Servern kommunizieren. o Alternativ kann /etc/resolv.conf von anderen Paketen verwaltet werden. In diesem Fall wird systemd-resolved sie fur DNS-Konfigurationsdaten auslesen. In diesem Betriebsmodus ist systemd-resolved Konsument statt Anbieter dieser Konfigurationsdaten. Beachten Sie, dass der ausgewahlte Betriebsmodus fur diese Datei vollautomatisch erkannt wird, abhangig davon, ob /etc/resolv.conf ein Symlink auf /run/systemd/resolve/resolv.conf ist oder 127.0.0.53 als DNS-Server auffuhrt. SIGNALE SIGUSR1 Beim Empfang des Prozesssignals SIGUSR1 wird systemd-resolved die Inhalte aller von ihm verwalteten DNS-Ressourcedatensatzzwischenspeicher sowie samtliche Funktionsstufeninformationen, die es uber konfigurierte DNS-Server herausfand, in das Systemprotokoll ausgeben. Hinzugefugt 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 - ausser zur Fehlersuche -, da systemd-resolved sowieso jedes Mal, wenn sich die Netzwerkkonfiguration des Rechners andert, seine Zwischenspeicher automatisch leert. Senden dieses Signals an systemd-resolved ist aquivalent zu dem Befehl resolvectl flush-caches, allerdings wird Letzterer empfohlen, da er synchron arbeitet. Hinzugefugt in Version 231. SIGRTMIN+1 Beim Empfang des Prozesssignals SIGRTMIN+1 wird systemd-resolved alles, was es uber die konfigurierten DNS-Server gelernt hat, vergessen. Insbesondere alle Informationen uber Server-Funktionalitatsunterstutzung werden entfernt, und die Ermittlungslogik fur die Serverfunktionalitat wird bei der nachsten Anfrage neu gestartet, beginnend mit der am hochsten augestatteten Funktionsstufe. Beachten Sie, dass es normalerweise nicht notwendig sein sollte, dies explizit anzufragen - ausser zur Fehlersuche -, da systemd-resolved sowieso jedes Mal, wenn sich die DNS-Serverkonfiguration andert, die gelernten Informationen vergisst. Senden dieses Signals an systemd-resolved ist aquivalent zu dem Befehl resolvectl reset-server-features, allerdings wird Letzterer empfohlen, da er synchron arbeitet. Hinzugefugt in Version 235. ZUGANGSBERECHTIGUNGEN systemd-resolved unterstutzt die durch ImportCredential=/LoadCredential=/SetCredential= implementierte Dienste-Zugangsberechtigungslogik (siehe systemd.exec(5) fur 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 uber /etc/systemd/resolved.conf, /etc/resolv.conf oder die Kernelbefehlszeile bereitgestellt wurde. Hinzugefugt 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 ausser Kraft. Hinzugefugt in Version 253. IP-PORTS Der Dienst systemd-resolved wartet auf den folgenden IP-Ports auf Anfragen: o 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. o Port 5353 auf allen lokalen Adressen, sowohl IPv4 als auch IPv6 (0.0.0.0 und ::0), fur 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 ausgewahlten >>Platzhalter<<-IP-Adresse gebunden ist und getrennte MulticastDNS link-lokale Geltungsbereiche fur jeden verwaltet werden, wobei berucksichtigt wird, ob MulticastDNS fur die Schnittstelle aktiviert ist. o Port 5355 auf allen lokalen Adressen, sowohl IPv4 als auch IPv6 (0.0.0.0 und ::0), fur LLMNR auf sowohl TCP wie auch UDP. Wie bei MulticastDNS wird die Filterung auf eingehenden Netzwerk-Schnittstellen durchgefuhrt. 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. RFC 3493 https://tools.ietf.org/html/rfc3493 2. RFC 6762 https://tools.ietf.org/html/rfc6762 3. Enhalt /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 schliesslich >>localhost<<. Falls die ersten zwei Abfragen (hoffentlich) fehlschlagen, wird systemd-resolved eine Anfrage fur die dritte Anfrage synthetisieren. Wird nss-dns mit einer Such-Domain eingesetzt, ist es daher essenziell, immer nss-files mit einer hoheren Prioritat zu konfigurieren und Abbildungen fur Namen bereitzustellen, die nicht mittels Such-Domains aufgelost werden sollen. 4. Es gibt derzeit mehr als 1.500 Domain-Namen oberster Stufe und regelmassig werden neue hinzugefugt, 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 gultiger globaler Name konnte durch einen lokalen Namen verschleiert werden und die Auflosung eines relativen lokalen Namens konnte plotzlich fehlschlagen, wenn eine neue Domain auf oberster Stufe erstellt wird oder wenn eine neue Unter-Domain einer Domain oberster Stufe registriert wird. Durch Auflosen jedes ubergebenen Namens als entweder relativ oder absolut wird diese Mehrdeutigkeit vermieden. UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann und Mario Blattermann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD-RESOLVED.SERVICE(8)