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

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 definiert. Daher wird eine Konfigurationsdatei
nur benötigt, wenn von diesen Vorgaben abgewichen werden muss. Standardmäßig enthält die
Konfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten Hinweis für den Administrator.
Diese Datei kann bearbeitet werden, um lokal Einstellungen zu ändern.

Wenn Pakete die Konfiguration anpassen müssen, können sie Konfigurationsschnipsel in
/usr/lib/systemd/*.conf.d/ oder /usr/local/lib/systemd/*.conf.d/installieren. Dateien in /etc/ sind für
den lokalen Administrator reserviert, der diese Logik dazu verwenden kann, die von Lieferantenpaketen
installierten Konfigurationsdateien außer Kraft zu setzen. Die Hauptkonfigurationsdatei wird vor jeder
anderen aus den Konfigurationsverzeichnissen gelesen und hat die niedrigste Priorität; Einträge in einer
Datei in jedem der Konfigurationsverzeichnisse setzen Einträge in der einzelnen Konfigurationsdatei 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 mit dem lexikographisch
letzten Namen Vorrang, falls mehrere Dateien die gleiche Option festlegen. Bei Optionen, die eine Liste
von Werten akzeptieren, werden Einträge zusammengefasst, wie sie in den lexikographisch sortierten
Dateien auftauchen. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige
Zahl und einen Gedankenstrich voranzustellen, um die Anordnung der Dateien zu vereinfachen.

Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu deaktivieren, wird empfohlen, einen
Symlink nach /dev/null in dem Konfigurationsverzeichnis /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. 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 festgelegt ist und
diese Datei existiert. Standardmäßig ist diese Einstellung die leere Liste.

FallbackDNS=
Eine Leerzeichen-getrennte Liste von IPv4- und IPv6-Adressen, die als Ausweich-DNS-Server verwandt
werden sollen. 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.

Domains=
Eine Leerraum-getrennte Liste von Domains. Diese Domains 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. 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 konfigurierten Such-Domains
verwandt, falls diese Einstellung nicht festgelegt ist und diese Datei existiert. Standardmäßig ist
diese Einstellung die leere Liste.

Den festgelegten Domain-Namen kann optional »~« vorangestellt werden. In diesem Fall definieren sie
keinen Suchpfad, sondern zu bevorzugende direkte DNS-Anfragen für die angezeigten Domains an die
DNS-Server, die mit der Systemeinstellung DNS= (siehe oben) konfiguriert wurden, falls zusätzliche,
linkbezogene DNS-Server bekannt sind. Falls keine linkbezogenen DNS-Server bekannt sind, hat die
»~«-Syntax keinen Effekt. Verwenden Sie das Konstrukt »~.« (das aus »~« zu Anzeige der Routing-Domain
und ».« zur Anzeige der DNS-Wurzel-Domain, die das implizite Suffix für alle DNS-Domains ist,
zusammengesetzt ist), um die mit DNS= definierten System-DNS-Server bevorzugt für alle Domains zu
verwenden.

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, deaktivert 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.

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.

DNSSEC=
Akzeptiert ein logisches Argument oder »allow-downgrade«. Falls wahr, werden alle DNS-Abfragen lokal
mit DNSSEC geprüft (außer LLMNR und Multicast-DNS). Falls erkannt wird, dass die Anwort auf die
Abfrageanfrage ungültig ist, wird ein Abfragefehler an die Anwendung 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, werden alle Überprüfungen fehlschlagen. Falls auf »allow-downgrade«
gesetzt, wird die 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 die
DNSSEC-Überprüfung anfällig für »downgrade«-Angriffe ist, bei denen ein Angreifer in der Lage sein
könnte, ein Downgrade auf den Modus ohne DNSSEC auszulösen, indem er künstlich DNS-Antworten
erstellt, die nahelegen, dass DNSSEC nicht unterstützt wird. Falls auf falsch gesetzt, werden
DNS-Abfragen nicht mit DNSSEC überprüft.

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 »allow-downgrade«.

DNSOverTLS=
Akzeptiert einen logischen Wert oder »opportunistic«. Falls wahr, werden alle Verbindungen zum Server
verschlüsselt. Beachten Sie, dass dieser Modus einen DNS-Server benötigt, der DNS-over-TLS
unterstützt und für seine IP über ein gültiges Zertifikat verfügt. Falls der DNS-Server DNS-over-TLS
nicht unterstützt, werden alle 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 nicht in der Lage ist, den Server zu authentifizieren, er ist für
»man-in-the-middle«-Angriffe verwundbar.

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 aus.

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 implizit ausgeschaltet ist, falls der konfigurierte
DNS-Server auf einer Rechner-lokalen IP-Adresse (wie 127.0.0.1 oder ::1) ist, um doppelte lokale
Zwischenspeicherung zu vermeiden.

DNSStubListener=
Akzeptiert ein logisches Argument oder »udp« oder »tcp«. Falls »udp«,wird ein Stub-Resolver auf der
Adresse 127.0.0.53 Port 53 auf UDP-Anfragen warten. Falls »tcp« wird der Stub auf der gleichen
Adresse 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.

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.

ReadEtcHosts=
Akzeptiert ein logisches Argument. Falls »yes« (die Vorgabe) wird der Stub-Resolver /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.

SIEHE AUCH

       systemd(1), systemd-resolved.service(8), systemd-networkd.service(8), dnssec-trust-anchors.d(5),
       resolv.conf(4)

ANMERKUNGEN

        1. RFC 4795
           https://tools.ietf.org/html/rfc4795

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

Ü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
       <debian-l10n-german@lists.debian.org>.

systemd 243                                                                                     RESOLVED.CONF(5)