Provided by: manpages-de_4.15.0-9_all 
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. Anfänglich
enthält die Hauptkonfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten
Hinweis für den Administrator. Lokal können diese Einstellungen außer Kraft gesetzt
werden, indem diese Datei bearbeitet wird oder durch die Erstellung von Ergänzungen, wie
nachfolgend beschrieben. Es 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.
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.
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 angegeben ist und
diese Datei existiert.
Die Domains, denen »~« vorangestellt wurde, heißen »Routing-Domains«. Alle hier
aufgeführten Domains (sowohl Such-Domains als auch 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 Routing-Domains
keine Effekt.
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, 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.
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 »no«.
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«.
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.
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.
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.
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
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
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.
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⟩.