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