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

bezeichnung
übersicht
beschreibung
positive vertrauensanker
negative vertrauensanker
siehe auch
anmerkungen
übersetzung

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