RESOLVED.CONF(5) resolved.conf RESOLVED.CONF(5) BEZEICHNUNG resolved.conf, resolved.conf.d - Konfigurationsdateien fur die Netzwerk-Namensauflosung UBERSICHT /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-Namensauflosung. KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE Die Standardkonfiguration wird wahrend der Kompilierung gesetzt. Daher wird eine Konfiguration nur benotigt, wenn von diesen Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei ist entweder /usr/lib/systemd/ oder /etc/systemd/ und enthalt die Vorgaben als auskommentierte Hinweise fur den Administrator. Lokal konnen diese Einstellungen durch die Erstellung von Erganzungen, wie nachfolgend beschrieben, ausser Kraft gesetzt werden. Zu diesem Zweck kann die Hauptkonfigurationsdatei (oder eine Kopie in /etc/, falls sie in /usr/ ausgeliefert wird) auch bearbeitet werden, allerdings wird empfohlen, Erganzungen fur lokale Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verandern. Zusatzlich zu der >>Haupt<<-Konfigurationsdatei, werden Erganzungs-Konfigurationsschnipsel aus /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese Erganzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen diese ausser Kraft. Dateien in den Konfigurationsunterverzeichnissen *.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen sortiert, unabhangig 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 Eintrage gesammelt, wie sie in den sortierten Dateien auftauchen. Wenn Pakete die Konfiguration anpassen mussen, konnen sie Erganzungen unter /usr/ installieren. Dateien in /etc/ sind fur den lokalen Administrator reserviert, der diese Logik verwenden kann, um die durch die Lieferantenpakete bereitgestellten Konfigurationsdateien ausser Kraft zu setzen. Um Erganzungen der Pakete ausser Kraft zu setzen, mussen Erganzungen verwandt werden, da die Hauptkonfigurationsdatei die niedrigste Prioritat hat. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl und einen Bindestrich voranzustellen, um die Sortierung der Dateien zu vereinfachen. Dies definiert auch ein Konzept von Erganzungsprioritaten, um es Distributionen zu ermoglichen, Erganzungen in einem bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte das Risiko reduzieren, dass eine Paketerganzung versehentlich durch Benutzer definierte Erganzungen ausser Kraft setzt. 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]<< verfugbar: 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<< fur IPv4 und >>[1111:2222::3333]:9953%sname#example.com<< fur IPv6 akzeptierbare vollstandige 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 Kompatibilitatsgrunden werden stattdessen alle in /etc/resolv.conf konfigurierten DNS-Server verwandt, falls diese Einstellung nicht angegeben ist und diese Datei existiert. Standardmassig ist diese Einstellung die leere Liste. Hinzugefugt in Version 213. FallbackDNS= Eine Leerzeichen-getrennte Liste von IPv4- und IPv6-Adressen, die als Ausweich-DNS-Server verwandt werden sollen. Bitte lesen Sie unter DNS= bezuglich 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. Hinzugefugt in Version 216. Domains= Eine Leeraum-getrennte Liste von Domains, denen optional >>~<< vorangestellt ist, die fur die zwei nachfolgend beschriebenen klaren Zwecke verwandt wird. Standardmassig die leere Liste. Alle Domains, denen keine >>~<< vorangestellt ist, werden als Suchmuster-Endungen bei der Auflosung 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 Kompatibilitatsgrunden werden stattdessen alle in /etc/resolv.conf mit dem Schlusselword search konfigurierten Such-Domains verwandt, falls diese Einstellung nicht angegeben ist und diese Datei existiert. Die Domains, denen >>~<< vorangestellt wurde, heissen >>nur-Routing-Domains<<. Alle hier aufgefuhrten 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 konnen 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 fur diesen Link bevorzugt fur alle Domains zu verwenden. Siehe >>Protokolle und Routing<< in systemd-resolved.service(8) fur 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 fur 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 konnen nicht dazu verwandt werden, nicht-hierarchische Nachschlagungen mittels MulticastDNS aufzulosen. Hinzugefugt in Version 229. LLMNR= Akzeptiert ein logisches Argument oder >>resolve<<. Steuert die Unterstutzung linklokaler Multicast-Namensauflosung (RFC 4795[1]) auf dem lokalen Rechner. Falls wahr, wird die vollstandige Unterstutzung fur den LLMNR-Beantworter und -Resolver aktiviert. Falls falsch, deaktiviert beide. Falls auf >>resolve<< gesetzt, wird nur die Resolver-Unterstutzung 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. Hinzugefugt in Version 216. MulticastDNS= Akzeptiert einen logischen Wert oder >>resolve<<. Steuert Multicast-DNS-Unterstutzung (RFC 6762[2]) auf dem lokalen Rechner. Falls wahr, aktiviert komplette Unterstutzung fur Multicast-DNS-Beantworter und -Resolver. Falls falsch, deaktiviert beide. Falls auf >>resolve<< gesetzt, wird nur die Resolver-Unterstutzung 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. Hinzugefugt in Version 234. DNSSEC= Akzeptiert ein logisches Argument oder >>allow-downgrade<<. Falls auf wahr gesetzt, werden alle DNS-Abfragen lokal auf DNSSEC uberpruft (ohne LLMNR und Multicast-DNS). Falls die Antwort auf eine Nachschlage-Anfrage als ungultig erkannt wird, wird ein Nachschlagefehler an die Anwendungen zuruckgegeben. Beachten Sie, dass dieser Modus einen DNS-Server benotigt, der DNSSEC unterstutzt. Falls der DNS-Server DNSSEC nicht korrekt unterstutzt, dann werden alle Uberprufungen fehlschlagen. Falls auf >>allow-downgrade<< gesetzt, wird DNSSEC-Uberprufung versucht, aber falls der Server DNSSEC nicht korrekt unterstutzt, wird der DNSSEC-Modus automatisch deaktiviert. Beachten Sie, dass in diesem Modus DNSSEC-Uberprufung anfallig fur >>downgrade<<-Angriffe ist, bei denen ein Angreifer in der Lage sein konnte, ein Downgrade auf einen Modus ohne DNSSEC auszulosen, indem er kunstlich eine DNS-Antwort erstellt, die nahelegt, dass DNSSEC nicht unterstutzt wird. Falls auf falsch gesetzt, werden alle DNS-Anfragen nicht mit DNSSEC uberpruft. In diesem Modus oder auf >>allow-downgrade<< und die Herunterstufung passiert ist, wird der Resolver Sicherheit ignorieren und bei allen weitergeleiteten Anfragen ist das Bit DNSSEC OK (DO) nicht gesetzt. Beachten Sie, dass die DNSSEC-Uberprufung die Abfrage zusatzlicher DNS-Daten benotigt und daher zu einer kleinen DNS-Abfragezeitverzogerung fuhrt. DNSSEC benotigt die Kenntnis von >>Vertrauensankern<<, um die Datenintegritat nachweisen zu konnen. Der Vertrauensanker fur die Internet-Wurzel-Domain ist in den Resolver eingebaut, zusatzliche Vertrauensanker konnen mittels dnssec-trust-anchors.d(5) definiert werden. Vertrauensanker konnen sich in regelmassigen Intervallen andern und alte Vertrauensanker konnen zuruckgezogen werden. In diesem Falle ist keine DNSSEC-Uberprufung moglich, bis lokal neue Vertrauensanker konfiguriert sind oder das Resolver-Softwarepaket mit dem neuen Wurzelvertrauensanker aktualisiert ist. Tatsachlich werden alle zukunftigen Abfragen fehlschlagen, wenn der eingebaute Vertrauensanker zuruckgezogen wird und DNSSEC= wahr ist, da nicht mehr nachgewiesen werden kann, ob Abfragen korrekt signiert oder gultig nicht signiert sind. Falls DNSSEC= auf >>allow-downgrade<< gesetzt ist, wird der Resolver in diesem Fall automatisch die DNSSEC-Uberprufung abschalten. Client-Programme, die DNS-Daten nachschlagen, werden informiert, ob das Abfragen mit DNSSEC uberpruft werden konnte oder ob die zuruckgelieferten Daten nicht gepruft werden konnten (entweder weil die Daten im DNS unsigniert vorlagen oder der DNS-Server DNSSEC nicht unterstutzte oder keine geeigneten Vertrauensanker bekannt waren). In letzterem Falle wird angenommen, dass das Client-Programm ein sekundares Schema einsetzt, um die zuruckgelieferten DNS-Daten zu uberprufen, falls dies notwendig sein sollte. Es wird empfohlen, DNSSEC= auf Systemen, bei denen es bekannt ist, dass der DNS-Server DNSSEC korrekt unterstutzt wird und wo Software- oder Vertrauensankeraktualisierungen regelmassig stattfinden, auf wahr zu setzen. Auf anderen Systemen wird empfohlen, DNSSEC= auf >>allow-downgrade<< zu setzen. Zusatzlich zu dieser globalen DNSSEC-Einstellung betreut systemd-networkd.service(8) auch link-lokale DNSSEC-Einstellungen. Fur System-DNS-Server (siehe oben) ist nur die globale DNSSEC-Einstellung wirksam. Fur link-bezogene DNS-Server ist die link-bezogene Einstellung wirksam, ausser sie wird zuruckgesetzt, dann wird stattdessen die globale Einstellung verwandt. Site-private DNS-Zonen stehen im Allgemeinen mit DNSSEC im Konflikt, ausser ein negativer (falls die private Zone nicht signiert ist) oder ein positiver (falls die private Zone signiert ist) Vertrauensanker ist fur sie konfiguriert. Falls der Modus >>allow-downgrade<< ausgewahlt 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. Standardmassig >>no<<. Hinzugefugt in Version 229. DNSOverTLS= Akzeptiert ein logisches Argument oder >>opportunistic<<. Falls wahr, werden alle Verbindungen zum Server verschlusselt. Beachten Sie, dass dieser Modus einen DNS-Server verlangt, der DNS-uber-TLS unterstutzt und ein gultiges 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 Offnen der TLS-Verbindung zu aktivieren. Andernfalls wird das Zertifikat gegen die IP des Servers gepruft. Falls der DNS-Server kein DNS-uber-TLS unterstutzt, werden DNS-Anfragen fehlschlagen. Falls auf >>opportunistic<< gesetzt, wird versucht, DNS-Anfragen verschlusselt mit DNS-uber-TLS zu versenden. Falls der DNS-Server TLS nicht unterstutzt, wird DNS-uber-TLS deaktiviert. Beachten Sie, dass in diesem Modus DNS-uber-TLS anfallig fur >>downgrade<<-Angriffe ist, bei denen ein Angreifer in der Lage sein konnte, ein Downgrade auf einen nichtverschlusselten Modus auszulosen, indem er kunstlich DNS-Antworten erstellt, die nahelegen, dass DNS-uber-TLS nicht unterstutzt wird. Falls auf falsch gesetzt, werden DNS-Abfragen uber UDP versandt. Beachten Sie, dass DNS-uber-TLS das Versenden zusatzlicher Daten fur die Einrichtung einer verschlusselten Verbindung benotigt und daher zu einer kleinen DNS-Abfragezeitverzogerung fuhrt. Beachten Sie, dass der Resolver im Modus >>opportunistic<< nicht in der Lage ist, den Server zu authentifizieren, er daher fur >>man-in-the-middle<<-Angriffe verwundbar ist. Zusatzlich zu dieser globalen DNSOverTLS-Einstellung betreut systemd-networkd.service(8) auch link-lokale DNSOverTLS-Einstellungen. Fur System-DNS-Server (siehe oben) ist nur die globale DNSOverTLS-Einstellung wirksam. Fur link-bezogene DNS-Server ist die link-bezogene Einstellung wirksam, ausser sie wird zuruckgesetzt, dann wird stattdessen die globale Einstellung verwandt. Standardmassig >>no<<. Hinzugefugt in Version 239. Cache= Akzeptiert ein logisches Argument oder >>no-negative<<. Falls >>yes<< (die Vorgabe), wird bei der Auflosung eines Domain-Namens, der bereits fruher abgefragt wurde, das bisherige Ergebnis zuruckgeliefert, solange es noch gultig ist, und daher erfolgt keine neue Netzwerkanfrage. Beachten Sie, dass das Abschalten der Zwischenspeicherung zu einer Leistungseinbusse fuhrt, die besonders hoch ist, falls DNSSEC verwandt wird. Falls >>no-negative<< werden nur positive Antworten zwischengespeichert. Beachten Sie, dass Zwischenspeicherung fur Rechner-lokale DNS-Server standardmassig ausgeschaltet ist. Siehe CacheFromLocalhost= fur Details. Hinzugefugt in Version 231. 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, wurde das Ergebnis nicht zwischengespeichert, um mogliche doppelte lokale Zwischenspeicherung zu vermeiden. Hinzugefugt in Version 248. 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 vollstandigen Funktionalitatsumfang des lokalen Resolvers bereit, einschliesslich LLMNR/MulticastDNS-Auflosung. 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 unverandert an den aktuellen vorgelagerten DNS-Server weitergeben (und zuruck), abernicht versuchen, die Nachrichten lokal zu verarbeiten und damit nicht die Gultigkeit von DNSSEC zu uberprufen oder LLMNR/MulticastDNS anzubieten. (Falls notwendig wird er aber auf DNS-uber-TLS-Kommunikation ubersetzen.) 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. Hinzugefugt in Version 232. 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 angehangt 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 unabhangig von dem mit DNSStubListener= konfigurierten primaren DNS-Stub ist und nur zusatzliche 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 zuruckgesetzt. Standardmassig 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 Hinzugefugt in Version 247. ReadEtcHosts= Akzeptiert ein logisches Argument. Falls >>yes<< (die Vorgabe) wird systemd-resolved /etc/hosts lesen und versuchen, Rechner oder Adressen durch Verwenden von Eintragen in der Datei aufzulosen, bevor er Anfragen an DNS-Server sendet. Hinzugefugt in Version 240. ResolveUnicastSingleLabel= Akzeptiert ein logisches Argument. Wenn falsch (die Vorgabe), wird systemd-resolved keine A und AAAA-Anfragen fur einzelstehende Namen uber klasssisches DNS auflosen. Beachten Sie, dass solche Namen weiterhin aufgelost werden, falls Such-Domains angegeben sind (siehe vorstehende Domains=) oder mittels anderer Mechanismen, insbesondere via LLMNR oder aus /etc/hosts. Wenn wahr, werden Anfragen fur einzelstehende Namen an globale DNS-Server weitergeleitet, selbst falls keine Such-Domains definiert sind. Diese Option wird zur Kompatibilitat mit Konfigurationen bereitgestellt, bei denen keine offentlichen DNS-Server verwandt werden. Die Weiterleitung von einzelstehenden Namen an Server, die sie nicht steuern konnen, folgt nicht dem Standard, siehe die IAB-Aussage[3], und kann zu Datenschutz- und Sicherheitsproblemen fuhren. Hinzugefugt in Version 246. StaleRetentionSec=SEKUNDEN Akzeptiert einen Zeitdauerwert, der die Zeitdauer bestimmt, die DNS-Ressourcen-Datensatze uber ihren >>Time To Live<< (TTL) hinaus im Zwischenspeicher behalten werden durfen. Dies erlaubt es, diese Datensatze als veraltete Datensatze zuruckzugeben. Standardmassig ist dieser Wert auf Null gesetzt. Dies bedeutet, dass DNS-Ressourcen-Datensatze nicht im Zwischenspeicher gespeichert werden, wenn ihr TTL ablauft. Dies ist nutzlich, wenn ein DNS-Server-Fehlschlag auftritt oder dieser nicht mehr erreichbar ist. In diesen Fallen verwendet systemd-resolved(8) die veralteten Datensatze, um DNS-Abfragen zu beantworten, insbesondere wenn keine gultige Antwort von den vorgelagerten DNS-Servern erhalten werden kann. Allerdings gilt dies nicht fur NXDOMAIN-Antworten, da diese weiterhin rundherum gultige Antworten sind. Diese Funktionalitat erhoht die Widerstandsfahigkeit gegen DNS-Infrastrukturfehlschlage und -unterbrechungen. systemd-resolved(8) versucht immer, zuerst die vorgelagerten DNS-Server zu erreichen, bevor es Client-Anwendungen veraltete Daten bereitstellt. Falls diese Funktionalitat aktiviert ist, wird der Zwischenspeicher nicht geleert, wenn Server gewechselt werden. Hinzugefugt in Version 254. 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/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 RESOLVED.CONF(5)