Hinzugefügt in Version 213.

Hinzugefügt in Version 216.

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.

Hinzugefügt in Version 216.

Hinzugefügt in Version 234.

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 DNS-Abfragen nicht mittels DNSSEC validiert.

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.

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.

Beachten Sie, dass Zwischenspeicherung für Rechner-lokale DNS-Server standardmäßig ausgeschaltet ist. Siehe CacheFromLocalhost= für Details.

Hinzugefügt in Version 231.

Hinzugefügt in Version 248.

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.

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.

Hinzugefügt in Version 240.

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[4], und kann zu Datenschutz- und Sicherheitsproblemen führen.

Hinzugefügt in Version 246.

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.