Provided by: manpages-de_4.13-4_all 
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 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.
• 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 Stub-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.
/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.
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. 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.
systemd 250 SYSTEMD-RESOLVED.SERVICE(8)