Provided by: manpages-de_4.21.0-2_all bug

BEZEICHNUNG

       resolved.conf, resolved.conf.d - Konfigurationsdateien für die Netzwerk-Namensauflösung

ÜBERSICHT

       /etc/systemd/resolved.conf

       /etc/systemd/resolved.conf.d/*.conf

       /run/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 ist entweder /usr/lib/systemd/ oder /etc/systemd/ und 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 »Haupt«-Konfigurationsdatei, 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 der Dateien zu
       vereinfachen. Dies definiert auch ein Konzept von Erweiterungsprioritäten, um es
       Distributionen zu ermöglichen, Erweiterungen in einem bestimmten Bereich auszuliefern, der
       unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte das Risiko reduzieren,
       dass eine Paketerweiterung versehentlich durch Benutzer definierte Erweiterungen außer
       Kraft setzt.

       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[1]) auf dem lokalen Rechner. Falls
           wahr, wird die vollständige Unterstützung für den LLMNR-Beantworter und -Resolver
           aktiviert. Falls falsch, 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[2]) auf dem lokalen Rechner. Falls wahr, aktiviert komplette Unterstützung
           für Multicast-DNS-Beantworter und -Resolver. Falls falsch, 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 wahr 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 falsch gesetzt, werden alle DNS-Anfragen nicht mit DNSSEC überprüft. In
           diesem Modus oder auf »allow-downgrade« und die Herunterstufung passiert ist, wird der
           Resolver Sicherheit ignorieren und bei allen weitergeleiteten Anfragen ist das Bit
           DNSSEC OK (DO) nicht gesetzt.

           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= wahr 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 wahr 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 wahr, 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 falsch 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 falsch (die Vorgabe), wird systemd-resolved
           keine A und AAAA-Anfragen für einzelstehende Namen über klasssisches 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 wahr, 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[3], 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. RFC 4795
           https://tools.ietf.org/html/rfc4795

        2. RFC 6762
           https://tools.ietf.org/html/rfc6762

        3. 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 ⟨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⟩.