Provided by: manpages-de_2.5-1_all bug

BEZEICHNUNG

       dnssec-trust-anchors.d, systemd.positive, systemd.negative -
       DNSSEC-Vertrauensankerkonfigurationsdatei

ÜBERSICHT

       /etc/dnssec-trust-anchors.d/*.positive

       /run/dnssec-trust-anchors.d/*.positive

       /usr/lib/dnssec-trust-anchors.d/*.positive

       /etc/dnssec-trust-anchors.d/*.negative

       /run/dnssec-trust-anchors.d/*.negative

       /usr/lib/dnssec-trust-anchors.d/*.negative

BESCHREIBUNG

       Die DNSSEC-Vertrauensankerkonfigurationsdatei definiert positive und negative
       Vertrauensanker, auf die systemd-resolved.service(8) DNSSEC-Integritätsnachweise basieren.

POSITIVE VERTRAUENSANKER

       Positive Vertrauensankerkonfigurationsdateien enthalten DNSKEY- und
       DS-Ressourcedatensatzdefinitionen, die als Basis für DNSSEC-Integritätsnachweise genutzt
       werden. Siehe RFC 4035, Abschnitt 4.4[1] für weitere Informationen über DNSSEC
       Vertrauensanker.

       Positive Vertrauensanker werden aus Dateien in den Verzeichnissen
       /etc/dnssec-trust-anchors, /run/dnssec-trust-anchors.d/ und
       /usr/lib/dnssec-trust-anchors.d/ mit der Endung .positive gelesen. Diese Verzeichnisse
       werden in der angegebenen Reihenfolge durchsucht und eine Vertrauensankerdatei mit dem
       gleichen Namen in einem früheren Pfad setzt eine Vertrauensankerdatei in einem späteren
       Pfad außer Kraft. Um eine in /usr/lib/dnssec-trust-anchors.d/ ausgelieferte
       Vertrauensankerdatei zu deaktivieren, reicht es, eine Datei mit identischem Namen in
       /etc/dnssec-trust-anchors.d/ oder /run/dnssec-trust-anchors.d/ bereitzustellen, die
       entweder leer oder ein Symlink auf /dev/null (»maskieren«) ist.

       Positive Vertrauensankerdateien sind einfache Textdateien, die DNS-Zonendateien ähneln,
       wie sie in RFC 1035, Abschnitt 5[2] dokumentiert sind. Ein DS- oder
       DNSKEY-Ressourcendatensatz darf pro Zeile aufgelistet werden. Leere Zeilen und Zeilen, die
       mit einem Semikolon (»;«) beginnen, werden ignoriert und als Kommentare betrachtet. Ein
       DS-Ressourcendatensatz wird wie im folgenden Beispiel festgelegt:

           . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5

       Das erste Wort legt die Domain fest, verwenden Sie ».« für die Wurzeldomain. Die Domain
       darf mit oder ohne führenden Punkt festgelegt werden, diese werden als äquivalent
       betrachtet. Das zweite Wort muss »IN« sein, das dritte Wort »DS«. Die folgenden Worte
       legen die Schlüssel-Markierung, den Signaturalgorithmus, den Digest-Algorithmus, gefolgt
       von dem hexadezimal kodierten Fingerabdruck fest. Siehe RFC 4034,Abschnitt 5[3] für
       Details über die genaue Syntax und Bedeutung dieser Felder.

       Alternativ dürfen DNSKEY-Ressourcendatensätze verwandt werden, um Vertrauensanker, wie in
       dem nachfolgenden Beispiel, zu definieren:

           . IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

       Das erste Wort legt wieder die Domain fest, das zweite Wort muss »IN«, gefolgt von
       »DNSKEY«, sein. Die nachfolgenden Wörter kodieren die DNSKEY-Schalter, Protokoll und
       Algorithmen-Felder, gefolgt von dem Base64-kodierten Schlüssel. Siehe RFC 4034, Abschnitt
       2[4] für Details über die genaue Syntax und Bedeutung dieser Felder.

       Falls mehrere DS- oder DNSKEY-Datensätze für die gleiche Domain definiert sind
       (möglicherweise sogar in verschiedenen Vertrauensankerdateien), werden alle Schlüssel
       benutzt und äquivalent als Basis für DNSSEC-Nachweise betrachtet.

       Beachten Sie, dass Systemd-resolved automatisch einen eingebauten Vertrauensanker für die
       Internet-Wurzeldomain verwenden wird, falls keine Vertrauensanker für die Wurzeldomain
       definiert sind. In den meisten Fällen ist es daher unnötig, einen expliziten Schlüssel mit
       Vertrauensankerdateien zu definieren. Der eingebaute Schlüssel wird deaktiviert, sobald
       mindestens ein Vertrauensankerschlüssel für die Wurzeldomain in einer Vertrauensankerdatei
       definiert ist.

       Es wird im Allgemeinen empfohlen, Vertrauensanker in DS-Ressourcendatensätzen statt in
       DNSKEY-Ressourcendatensätzen zu kodieren.

       Falls ermittelt wird, dass ein über ein DS-Datensatz festgelegter Vertrauensanker
       zurückgezogen wurde, wird er für die Laufzeit aus der Vertrauensankerdatenbank entfernt.
       Siehe RFC 5011[5] für Details über zurückgezogene Vertrauensanker. Beachten Sie, dass
       Systemd-resolved seine Vertrauensankerdatenbank nicht automatisch von DNS-Servern
       aktualisieren wird. Es wird stattdessen empfohlen, dass Sie die Resolver-Software
       aktualisieren oder neue Vertrauensanker aktualisieren, indem Sie sie in neue
       Vertrauensankerdateien hinzufügen.

       Der aktuelle DNSSEC-Vertrauensanker für die Wurzeldomain des Internets ist unter der Seite
       IANA Trust Anchor and Keys[6] verfügbar.

NEGATIVE VERTRAUENSANKER

       Negative Vertrauensanker definieren Domains, bei denen DNSSEC-Überprüfung abgeschaltet
       werden soll. Negative Vertrauensankerdateien werden am gleichen Ort wie positive
       Vertrauensankerdateien gefunden. Sie folgen den gleichen Regeln zum Außer-Kraft-Setzen.
       Sie sind Textdateien mit der Endung .negative. Leere Zeilen und Zeilen, deren erstes
       Zeichen ein »;« ist, werden ignoriert. Jede Zeile legt einen Domain-Namen fest, der die
       Wurzel eines DNS-Unterbaums ist, für den Überprüfung deaktiviert werden soll.

       Negative Vertrauensanker sind für private DNS-Unterbäume nützlich, die nicht aus der
       Internet-DNS-Hierarchie referenziert und nicht signiert sind.

       RFC 7646[7] für Details über negative Vertrauensanker.

       Falls keine negativen Vertrauensankerdateien konfiguriert sind, wird eine eingebaute
       Gruppe von gut bekannten privaten DNS-Zone-Domains als negative Vertrauensanker benutzt.

       Es ist auch möglich, pro Schnittstelle negative Vertrauensanker zu definieren, indem die
       Einstellung DNSSECNegativeTrustAnchors= in systemd.network(5)-Dateien verwandt wird.

SIEHE AUCH

       systemd(1), systemd-resolved.service(8), resolved.conf(5), systemd.network(5)

ANMERKUNGEN

        1. RFC 4035, Abschnitt 4.4
           https://tools.ietf.org/html/rfc4035#section-4.4

        2. RFC 1035, Abschnitt 5
           https://tools.ietf.org/html/rfc1035#section-5

        3. RFC 4034, Abschnitt 5
           https://tools.ietf.org/html/rfc4034#section-5

        4. RFC 4034, Abschnitt 2
           https://tools.ietf.org/html/rfc4034#section-2

        5. RFC 5011
           https://tools.ietf.org/html/rfc5011

        6. IANA Vertrauensanker und -Schlüssel
           https://data.iana.org/root-anchors/root-anchors.xml

        7. RFC 7646
           https://tools.ietf.org/html/rfc7646

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