Provided by: manpages-de_4.15.0-9_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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.