dnssec-trust-anchors.d, systemd.positive, systemd.negative -
DNSSEC-Vertrauensankerkonfigurationsdatei
/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
Die DNSSEC-Vertrauensankerkonfigurationsdatei definiert positive und negative
Vertrauensanker, auf denen
systemd-resolved.service(8)
DNSSEC-Integritätsnachweise basieren.
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 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.
systemd(1),
systemd-resolved.service(8),
resolved.conf(5),
systemd.network(5)
- 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
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<
[email protected]> 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