RESOLVED.CONF(5) resolved.conf RESOLVED.CONF(5)

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

/etc/systemd/resolved.conf

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

/run/systemd/resolved.conf.d/*.conf

/usr/lib/systemd/resolved.conf.d/*.conf

Diese Konfigurationsdateien steuern lokale DNS- und LLMNR-Namensauflösung.

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

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. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl und einen Bindestrich voranzustellen, um die Sortierung der Dateien zu vereinfachen.

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.

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

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 festgelegt ist und diese Datei existiert.

The domains prefixed with "~" are called "routing domains". All domains listed here (both search domains and routing domains after removing the "~" prefix) define a search path that preferably directs DNS queries to this interface. This search path has an effect only when suitable per-link DNS servers are known. Such servers may be defined through the DNS= setting (see above) and dynamically at run time, for example from DHCP leases. If no per-link DNS servers are known, routing domains have no effect.

Verwenden Sie das Konstrukt »~.« (das aus »~«, um eine 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.

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

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

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

1.
RFC 4795
2.
RFC 6762
3.
IAB-Aussage

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 246