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 denen 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 (»maskiert«) ist.

Positive Vertrauensankerdateien sind einfache Textdateien, die DNS-Zonendateien ähneln, wie sie in RFC 1035, Abschnitt 5[2] dokumentiert sind. Pro Zeile darf ein DS- oder DNSKEY-Ressourcendatensatz aufgelistet werden. Leere Zeilen und Zeilen, die mit »#« oder »;« beginnen, werden ignoriert, was zur Kommentierung verwandt werden kann. 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 angegeben werden, diese werden als äquivalent betrachtet. Das zweite Wort muss »IN« sein, das dritte Wort »DS«. Die folgenden Wörter 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 einen 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-Vertrauensanker und -Schlüssel[6] verfügbar.

NEGATIVE VERTRAUENSANKER¶

Negative Vertrauensanker definieren Domains, bei denen die 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 die Überprüfung deaktiviert werden soll. Beispiel:

# Inverse IPv4-Abbildungen
10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
…
# Einige angepasste Domains
prod
stag

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

2.

RFC 1035, Abschnitt 5

3.

RFC 4034, Abschnitt 5

4.

RFC 4034, Abschnitt 2

5.

RFC 5011

6.

IANA-Vertrauensanker und -Schlüssel

7.

RFC 7646

Ü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 die Mailingliste der Übersetzer.