Provided by: manpages-de_4.27.0-1_all 
BEZEICHNUNG
resolved.conf, resolved.conf.d - Konfigurationsdateien für die Netzwerk-Namensauflösung
ÜBERSICHT
/etc/systemd/resolved.conf
/run/systemd/resolved.conf
/usr/local/lib/systemd/resolved.conf
/usr/lib/systemd/resolved.conf
/etc/systemd/resolved.conf.d/*.conf
/run/systemd/resolved.conf.d/*.conf
/usr/local/lib/systemd/resolved.conf.d/*.conf
/usr/lib/systemd/resolved.conf.d/*.conf
BESCHREIBUNG
Diese Konfigurationsdateien steuern lokale DNS- und LLMNR-Namensauflösung.
KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE
Die Standardkonfiguration wird während der Kompilierung gesetzt. Daher wird eine Konfiguration nur
benötigt, wenn von diesen Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei wird aus einem
der aufgeführten Verzeichnisse in der Prioritätsreihenfolge geladen, nur die zuerst gefundene Datei wird
verwandt: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. Die
Lieferantenversion der Datei enthält die Vorgaben als auskommentierte Hinweise für den Administrator.
Lokal können diese Einstellungen durch die Erstellung von Ergänzungen, wie nachfolgend beschrieben, außer
Kraft gesetzt werden. Zu diesem Zweck kann die Hauptkonfigurationsdatei (oder eine Kopie in /etc/, falls
sie in /usr/ ausgeliefert wird) auch bearbeitet werden, allerdings wird empfohlen, Ergänzungen für lokale
Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verändern.
Zusätzlich zu der Hauptkonfigurationsdatei, werden Ergänzungs-Konfigurationsschnipsel aus
/usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese
Ergänzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen diese außer Kraft. Dateien in den
Konfigurationsunterverzeichnissen *.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen
sortiert, unabhängig davon, in welchem Unterverzeichnis sie sich befinden. Bei Optionen, die nur einen
einzelnen Wert akzeptieren, hat der Eintrag in der Datei, die als letztes in der Sortierung folgt,
Vorrang, falls mehrere Dateien die gleiche Option angeben. Bei Optionen, die eine Liste von Werten
akzeptieren, werden Einträge gesammelt, wie sie in den sortierten Dateien auftauchen.
Wenn Pakete die Konfiguration anpassen müssen, können sie Ergänzungen unter /usr/ installieren. Dateien
in /etc/ sind für den lokalen Administrator reserviert, der diese Logik verwenden kann, um die durch die
Lieferantenpakete bereitgestellten Konfigurationsdateien außer Kraft zu setzen. Um Ergänzungen der Pakete
außer Kraft zu setzen, müssen Ergänzungen verwandt werden, da die Hauptkonfigurationsdatei die niedrigste
Priorität hat. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl
und einen Bindestrich voranzustellen, um die Sortierung zu vereinfachen. Dies definiert auch ein Konzept
von Ergänzungsprioritäten, um es Betriebssystemlieferanten zu ermöglichen, Ergänzungen in einem
bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte
das Risiko reduzieren, dass eine Paketergänzung versehentlich durch Benutzer definierte Ergänzungen außer
Kraft setzt. Es wird empfohlen, den Bereich 10-40 für Ergänzungen in /usr/ und den Bereich 60-90 für
Ergänzungen in /etc/ und /run/ zu verwenden um sicherzustellen, dass lokale und flüchtige Ergänzungen
Priorität gegenüber Ergänzungen haben, die vom Betriebssystemlieferanten geliefert werden.
Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu deaktivieren, wird empfohlen, einen
Symlink nach /dev/null in dem Konfigurationsverzeichnis in /etc/ mit dem gleichen Dateinamen wie die
Konfigurationsdatei des Lieferanten abzulegen.
OPTIONEN
Die folgenden Optionen sind im Abschnitt »[Resolve]« verfügbar:
DNS=
Eine Leerzeichen-getrennte Liste von IPv4- und IPv6-Adressen, die als System-DNS-Server verwandt
werden sollen. Jede Adresse kann optional eine durch »:« abgetrennte Port-Nummer, einen mit »%«
abgetrennten Netzwerkschnittstellennamen oder -Index und eine durch »#« abgetrennte
Server-Namensanzeige (SNI) akzeptieren. Wenn eine IPv6-Adresse mit einer Port-Nummer angegeben wird,
dann muss die Adresse in eckige Klammern eingeschlossen werden. Das bedeutet, dass
»111.222.333.444:9953%sname#example.com« für IPv4 und »[1111:2222::3333]:9953%sname#example.com« für
IPv6 akzeptierbare vollständige Formate sind. DNS-Anfragen werden zu einem der gelisteten DNS-Server
und gleichzeitig zu geeigneten, linkbezogenen DNS-Servern, die mittels systemd-networkd.service(8)
erlangt oder zur Laufzeit durch externe Anwendungen gesetzt wurden, gesandt. Aus
Kompatibilitätsgründen werden stattdessen alle in /etc/resolv.conf konfigurierten DNS-Server
verwandt, falls diese Einstellung nicht angegeben ist und diese Datei existiert. Standardmäßig ist
diese Einstellung die leere Liste.
Hinzugefügt in Version 213.
FallbackDNS=
Eine Leerzeichen-getrennte Liste von IPv4- und IPv6-Adressen, die als Ausweich-DNS-Server verwandt
werden sollen. Bitte lesen Sie unter DNS= bezüglich akzeptierbarer Adressformate. Alle mittels
systemd-networkd.service(8) erlangten linkbezogenen DNS-Server haben vor dieser Einstellung Vorrang,
genauso wie oben mittels DNS= gesetzte Server oder /etc/resolv.conf. Diese Einstellung wird daher nur
verwandt, falls keine andere DNS-Server-Information bekannt ist. Falls diese Option nicht angegeben
ist, wird stattdessen eine einkompilierte Liste von DNS-Servern verwandt.
Hinzugefügt in Version 216.
Domains=
Eine Leeraum-getrennte Liste von Domains, denen optional »~« vorangestellt ist, die für die zwei
nachfolgend beschriebenen klaren Zwecke verwandt wird. Standardmäßig die leere Liste.
Alle Domains, denen keine »~« vorangestellt ist, werden als Suchmuster-Endungen bei der Auflösung von
nicht-hierarchischen Rechnernamen (Domain-Namen, die keinen Punkt enthalten) verwandt, um sie zu
voll-qualifizierten Domain-Namen (FQDNs) zu qualifizieren. Diese »Such-Domains« werden strikt in der
definierten Reihenfolge verarbeitet, bis der Name mit der Endung gefunden wurde. Aus
Kompatibilitätsgründen werden stattdessen alle in /etc/resolv.conf mit dem Schlüsselword search
konfigurierten Such-Domains verwandt, falls diese Einstellung nicht angegeben ist und diese Datei
existiert.
Die Domains, denen »~« vorangestellt wurde, heißen »nur-Routing-Domains«. Alle hier aufgeführten
Domains (sowohl Such-Domains als auch nur-Routing-Domains nach der Entfernung der vorangestellten
»~«) definieren einen Suchpfad, der DNS-Anfragen bevorzugt zu dieser Schnittstelle leitet. Dieser
Suchpfad hat nur einen Effekt, wenn geeignete linkbezogene DNS-Server bekannt sind. Solche Server
können mittels der Einstellung DNS= (siehe oben) und dynamisch zur Laufzeit definiert werden,
beispielsweise aus DHCP-Leases. Falls keine linkbezogene DNS-Server bekannt sind, haben
nur-Routing-Domains keine Auswirkung.
Verwenden Sie das Konstrukt »~.« (das aus »~«, um eine nur-Routing-Domain anzuzeigen und ».«, um die
DNS-Wurzel-Domain anzuzeigen, die allen DNS-Domains implizit vorangestellt ist, zusammengestellt
ist), um DNS-Server für diesen Link bevorzugt für alle Domains zu verwenden.
Siehe »Protokolle und Routing« in systemd-resolved.service(8) für Details dazu, wie Such- und
nur-Routing-Domains verwandt werden.
Beachten Sie, dass die Konfiguration der MulticastDNS-Domain »local« als Such- oder
Weiterleitungs-Domain die Auswirkung hat, dass Nachschlage-Weiterleitungen für diese Domain an
klassisches Unicast-DNS erfolgt. Dies kann zur Bereitstellung mit veralteten Installationen verwandt
werden, die diese Domain in einem Unicast-DNS-Kontext verwenden, obwohl die IANA diese Domain reinen
MulticastDNS-Zwecken zugewiesen hat. Such- und Weiterleitungs-Domains sind ein Unicast-DNS-Konzept,
sie können nicht dazu verwandt werden, nicht-hierarchische Nachschlagungen mittels MulticastDNS
aufzulösen.
Hinzugefügt in Version 229.
LLMNR=
Akzeptiert ein logisches Argument oder »resolve«. Steuert die Unterstützung linklokaler
Multicast-Namensauflösung (RFC 4795[2]) auf dem lokalen Rechner. Falls true, wird die vollständige
Unterstützung für den LLMNR-Beantworter und -Resolver aktiviert. Falls false, deaktiviert beide.
Falls auf »resolve« gesetzt, wird nur die Resolver-Unterstützung aktiviert, aber die Beantwortung ist
deaktiviert. Beachten Sie, dass systemd-networkd.service(8) auch linkbezogene LLMNR-Einstellungen
verwaltet. LLMNR wird auf einem Link nur aktiviert, falls die linkbezogene und die globale
Einstellung eingeschaltet ist.
Hinzugefügt in Version 216.
MulticastDNS=
Akzeptiert einen logischen Wert oder »resolve«. Steuert Multicast-DNS-Unterstützung (RFC 6762[3]) auf
dem lokalen Rechner. Falls true, aktiviert komplette Unterstützung für Multicast-DNS-Beantworter und
-Resolver. Falls false, deaktiviert beide. Falls auf »resolve« gesetzt, wird nur die
Resolver-Unterstützung aktiviert, aber die Beantwortung ist deaktiviert. Beachten Sie, dass
systemd-networkd.service(8) auch linkbezogene Multicast-Einstellungen verwaltet. Multicast wird auf
einem Link nur aktiviert, falls die linkbezogene und die globale Einstellung eingeschaltet ist.
Hinzugefügt in Version 234.
DNSSEC=
Akzeptiert ein logisches Argument oder »allow-downgrade«.
Falls auf true gesetzt, werden alle DNS-Abfragen lokal auf DNSSEC überprüft (ohne LLMNR und
Multicast-DNS). Falls die Antwort auf eine Nachschlage-Anfrage als ungültig erkannt wird, wird ein
Nachschlagefehler an die Anwendungen zurückgegeben. Beachten Sie, dass dieser Modus einen DNS-Server
benötigt, der DNSSEC unterstützt. Falls der DNS-Server DNSSEC nicht korrekt unterstützt, dann werden
alle Überprüfungen fehlschlagen.
Falls auf »allow-downgrade« gesetzt, wird DNSSEC-Überprüfung versucht, aber falls der Server DNSSEC
nicht korrekt unterstützt, wird der DNSSEC-Modus automatisch deaktiviert. Beachten Sie, dass in
diesem Modus DNSSEC-Überprüfung anfällig für »downgrade«-Angriffe ist, bei denen ein Angreifer in der
Lage sein könnte, ein Downgrade auf einen Modus ohne DNSSEC auszulösen, indem er künstlich eine
DNS-Antwort erstellt, die nahelegt, dass DNSSEC nicht unterstützt wird.
Falls auf false gesetzt, werden DNS-Abfragen nicht mittels DNSSEC validiert.
Beachten Sie, dass die DNSSEC-Überprüfung die Abfrage zusätzlicher DNS-Daten benötigt und daher zu
einer kleinen DNS-Abfragezeitverzögerung führt.
DNSSEC benötigt die Kenntnis von »Vertrauensankern«, um die Datenintegrität nachweisen zu können. Der
Vertrauensanker für die Internet-Wurzel-Domain ist in den Resolver eingebaut, zusätzliche
Vertrauensanker können mittels dnssec-trust-anchors.d(5) definiert werden. Vertrauensanker können
sich in regelmäßigen Intervallen ändern und alte Vertrauensanker können zurückgezogen werden. In
diesem Falle ist keine DNSSEC-Überprüfung möglich, bis lokal neue Vertrauensanker konfiguriert sind
oder das Resolver-Softwarepaket mit dem neuen Wurzelvertrauensanker aktualisiert ist. Tatsächlich
werden alle zukünftigen Abfragen fehlschlagen, wenn der eingebaute Vertrauensanker zurückgezogen wird
und DNSSEC= true ist, da nicht mehr nachgewiesen werden kann, ob Abfragen korrekt signiert oder
gültig nicht signiert sind. Falls DNSSEC= auf »allow-downgrade« gesetzt ist, wird der Resolver in
diesem Fall automatisch die DNSSEC-Überprüfung abschalten.
Client-Programme, die DNS-Daten nachschlagen, werden informiert, ob das Abfragen mit DNSSEC überprüft
werden konnte oder ob die zurückgelieferten Daten nicht geprüft werden konnten (entweder weil die
Daten im DNS unsigniert vorlagen oder der DNS-Server DNSSEC nicht unterstützte oder keine geeigneten
Vertrauensanker bekannt waren). In letzterem Falle wird angenommen, dass das Client-Programm ein
sekundäres Schema einsetzt, um die zurückgelieferten DNS-Daten zu überprüfen, falls dies notwendig
sein sollte.
Es wird empfohlen, DNSSEC= auf Systemen, bei denen es bekannt ist, dass der DNS-Server DNSSEC korrekt
unterstützt wird und wo Software- oder Vertrauensankeraktualisierungen regelmäßig stattfinden, auf
true zu setzen. Auf anderen Systemen wird empfohlen, DNSSEC= auf »allow-downgrade« zu setzen.
Zusätzlich zu dieser globalen DNSSEC-Einstellung betreut systemd-networkd.service(8) auch link-lokale
DNSSEC-Einstellungen. Für System-DNS-Server (siehe oben) ist nur die globale DNSSEC-Einstellung
wirksam. Für link-bezogene DNS-Server ist die link-bezogene Einstellung wirksam, außer sie wird
zurückgesetzt, dann wird stattdessen die globale Einstellung verwandt.
Site-private DNS-Zonen stehen im Allgemeinen mit DNSSEC im Konflikt, außer ein negativer (falls die
private Zone nicht signiert ist) oder ein positiver (falls die private Zone signiert ist)
Vertrauensanker ist für sie konfiguriert. Falls der Modus »allow-downgrade« ausgewählt ist, wird
versucht, alle Site-privaten DNS-Zonen zu erkennen, die oberste Domains (Top-Level Domains, TLDs)
verwenden, die dem DNS-Wurzelserver nicht bekannt sind. Diese Logik funktioniert nicht in allen
Installationen privater Zonen.
Standardmäßig »no«.
Hinzugefügt in Version 229.
DNSOverTLS=
Akzeptiert ein logisches Argument oder »opportunistic«. Falls true, werden alle Verbindungen zum
Server verschlüsselt. Beachten Sie, dass dieser Modus einen DNS-Server verlangt, der DNS-über-TLS
unterstützt und ein gültiges Zertifikat hat. Falls der Rechnername in DNS= in dem Format
»Adresse#Server-Name« angegeben wurde, wird dieser zum Validieren seiner Zertifikate verwandt und
auch, um Server-Namensanzeige (SNI) beim Öffnen der TLS-Verbindung zu aktivieren. Andernfalls wird
das Zertifikat gegen die IP des Servers geprüft. Falls der DNS-Server kein DNS-über-TLS unterstützt,
werden DNS-Anfragen fehlschlagen.
Falls auf »opportunistic« gesetzt, wird versucht, DNS-Anfragen verschlüsselt mit DNS-über-TLS zu
versenden. Falls der DNS-Server TLS nicht unterstützt, wird DNS-über-TLS deaktiviert. Beachten Sie,
dass in diesem Modus DNS-über-TLS anfällig für »downgrade«-Angriffe ist, bei denen ein Angreifer in
der Lage sein könnte, ein Downgrade auf einen nichtverschlüsselten Modus auszulösen, indem er
künstlich DNS-Antworten erstellt, die nahelegen, dass DNS-über-TLS nicht unterstützt wird. Falls auf
false gesetzt, werden DNS-Abfragen über UDP versandt.
Beachten Sie, dass DNS-über-TLS das Versenden zusätzlicher Daten für die Einrichtung einer
verschlüsselten Verbindung benötigt und daher zu einer kleinen DNS-Abfragezeitverzögerung führt.
Beachten Sie, dass der Resolver im Modus »opportunistic« nicht in der Lage ist, den Server zu
authentifizieren, er daher für »man-in-the-middle«-Angriffe verwundbar ist.
Zusätzlich zu dieser globalen DNSOverTLS-Einstellung betreut systemd-networkd.service(8) auch
link-lokale DNSOverTLS-Einstellungen. Für System-DNS-Server (siehe oben) ist nur die globale
DNSOverTLS-Einstellung wirksam. Für link-bezogene DNS-Server ist die link-bezogene Einstellung
wirksam, außer sie wird zurückgesetzt, dann wird stattdessen die globale Einstellung verwandt.
Standardmäßig »no«.
Hinzugefügt in Version 239.
Cache=
Akzeptiert ein logisches Argument oder »no-negative«. Falls »yes« (die Vorgabe), wird bei der
Auflösung eines Domain-Namens, der bereits früher abgefragt wurde, das bisherige Ergebnis
zurückgeliefert, solange es noch gültig ist, und daher erfolgt keine neue Netzwerkanfrage. Beachten
Sie, dass das Abschalten der Zwischenspeicherung zu einer Leistungseinbuße führt, die besonders hoch
ist, falls DNSSEC verwandt wird. Falls »no-negative« werden nur positive Antworten
zwischengespeichert.
Beachten Sie, dass Zwischenspeicherung für Rechner-lokale DNS-Server standardmäßig ausgeschaltet ist.
Siehe CacheFromLocalhost= für Details.
Hinzugefügt in Version 231.
CacheFromLocalhost=
Akzeptiert einen logischen Wert als Argument. Falls »no« (die Vorgabe) und die Antworten von einer
Rechner-lokalen IP-Adresse (wie 127.0.0.1 oder ::1) kamen, würde das Ergebnis nicht
zwischengespeichert, um mögliche doppelte lokale Zwischenspeicherung zu vermeiden.
Hinzugefügt in Version 248.
DNSStubListener=
Akzeptiert ein logisches Argument oder »udp« oder »tcp«. Falls »udp«, wird ein Stub-Resolver auf den
Adressen 127.0.0.53 und 127.0.0.54, Port 53 auf UDP-Anfragen warten. Falls »tcp« wird der Stub auf
den gleichen Adressen und dem gleichen Port auf Anfragen warten. Falls »yes« (die Vorgabe) wird der
Stub auf sowohl UDP- als auch TCP-Anfragen warten. Falls »no« ist der Stub deaktiviert.
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.)
Beachten Sie, dass der DNS-Stub implizit ausgeschaltet wird, wenn die Adresse und der Port, an dem er
auf Anfragen warten soll, bereits verwandt werden.
Hinzugefügt in Version 232.
DNSStubListenerExtra=
Akzeptiert eine IPv4- oder IPv6-Adresse, auf der auf Anfragen gewartet werden soll. Der Adresse kann
optional, durch einen »:« abgetrennt, ein Protokollname (»udp« oder »tcp«) vorangestellt werden.
Falls das Protokoll nicht angegeben ist, wird der Dienst sowohl auf UDP als auch TCP auf Anfragen
warten. Es kann auch optional, durch einen »:« abgetrennt, eine numerische Port-Nummer angehängt
werden. Wird eine IPv6-Adresse mit einer Port-Nummer angegeben, dann muss die Adresse in eckige
Klammern eingeschlossen werden. Falls der Port nicht angegeben ist, dann nutzt der Dienst den Port
53. Beachten Sie, dass dies unabhängig von dem mit DNSStubListener= konfigurierten primären DNS-Stub
ist und nur zusätzliche Sockets konfiguriert, bei denen auf Anfragen gewartet werden soll. Diese
Option kann mehrfach angegeben werden. Falls eine leere Zeichenkette zugewiesen wird, dann werden
alle vorhergehenden Zuweisungen zurückgesetzt. Standardmäßig nicht gesetzt.
Beispiele:
DNSStubListenerExtra=192.168.10.10
DNSStubListenerExtra=2001:db8:0:f102::10
DNSStubListenerExtra=192.168.10.11:9953
DNSStubListenerExtra=[2001:db8:0:f102::11]:9953
DNSStubListenerExtra=tcp:192.168.10.12
DNSStubListenerExtra=udp:2001:db8:0:f102::12
DNSStubListenerExtra=tcp:192.168.10.13:9953
DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953
Hinzugefügt in Version 247.
ReadEtcHosts=
Akzeptiert ein logisches Argument. Falls »yes« (die Vorgabe) wird systemd-resolved /etc/hosts lesen
und versuchen, Rechner oder Adressen durch Verwenden von Einträgen in der Datei aufzulösen, bevor er
Anfragen an DNS-Server sendet.
Hinzugefügt in Version 240.
ResolveUnicastSingleLabel=
Akzeptiert ein logisches Argument. Wenn false (die Vorgabe), wird systemd-resolved keine A und
AAAA-Anfragen für einzelstehende Namen über klassisches DNS auflösen. Beachten Sie, dass solche Namen
weiterhin aufgelöst werden, falls Such-Domains angegeben sind (siehe vorstehende Domains=) oder
mittels anderer Mechanismen, insbesondere via LLMNR oder aus /etc/hosts. Wenn true, werden Anfragen
für einzelstehende Namen an globale DNS-Server weitergeleitet, selbst falls keine Such-Domains
definiert sind.
Diese Option wird zur Kompatibilität mit Konfigurationen bereitgestellt, bei denen keine öffentlichen
DNS-Server verwandt werden. Die Weiterleitung von einzelstehenden Namen an Server, die sie nicht
steuern können, folgt nicht dem Standard, siehe die IAB-Aussage[4], und kann zu Datenschutz- und
Sicherheitsproblemen führen.
Hinzugefügt in Version 246.
StaleRetentionSec=SEKUNDEN
Akzeptiert einen Zeitdauerwert, der die Zeitdauer bestimmt, die DNS-Ressourcen-Datensätze über ihren
»Time To Live« (TTL) hinaus im Zwischenspeicher behalten werden dürfen. Dies erlaubt es, diese
Datensätze als veraltete Datensätze zurückzugeben. Standardmäßig ist dieser Wert auf Null gesetzt.
Dies bedeutet, dass DNS-Ressourcen-Datensätze nicht im Zwischenspeicher gespeichert werden, wenn ihr
TTL abläuft.
Dies ist nützlich, wenn ein DNS-Server-Fehlschlag auftritt oder dieser nicht mehr erreichbar ist. In
diesen Fällen verwendet systemd-resolved(8) die veralteten Datensätze, um DNS-Abfragen zu
beantworten, insbesondere wenn keine gültige Antwort von den vorgelagerten DNS-Servern erhalten
werden kann. Allerdings gilt dies nicht für NXDOMAIN-Antworten, da diese weiterhin rundherum gültige
Antworten sind. Diese Funktionalität erhöht die Widerstandsfähigkeit gegen
DNS-Infrastrukturfehlschläge und -unterbrechungen.
systemd-resolved(8) versucht immer, zuerst die vorgelagerten DNS-Server zu erreichen, bevor es
Client-Anwendungen veraltete Daten bereitstellt. Falls diese Funktionalität aktiviert ist, wird der
Zwischenspeicher nicht geleert, wenn Server gewechselt werden.
Hinzugefügt in Version 254.
SIEHE AUCH
systemd(1), systemd-resolved.service(8), systemd-networkd.service(8), dnssec-trust-anchors.d(5),
resolv.conf(5)
ANMERKUNGEN
1. 💣💥🧨💥💥💣 Bitte beachten Sie, dass diese Konfigurationsdateien zu allen Zeiten verfügbar sein
müssen. Falls /usr/local/ eine separate Partition ist, könnte diese während des frühen Systemstarts
nicht verfügbar sein und darf dann nicht für Konfiguration verwandt werden.
2. RFC 4795
https://tools.ietf.org/html/rfc4795
3. RFC 6762
https://tools.ietf.org/html/rfc6762
4. IAB-Aussage
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> 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: debian-l10n-german@lists.debian.org.
systemd 257.6 RESOLVED.CONF(5)