.\" -*- coding: UTF-8 -*- '\" t .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH DNSSEC\-TRUST\-ANCHORS\&.D 5 "" "systemd 247" dnssec\-trust\-anchors.d .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH BEZEICHNUNG dnssec\-trust\-anchors.d, systemd.positive, systemd.negative \- DNSSEC\-Vertrauensankerkonfigurationsdatei .SH ÜBERSICHT .PP /etc/dnssec\-trust\-anchors\&.d/*\&.positive .PP /run/dnssec\-trust\-anchors\&.d/*\&.positive .PP /usr/lib/dnssec\-trust\-anchors\&.d/*\&.positive .PP /etc/dnssec\-trust\-anchors\&.d/*\&.negative .PP /run/dnssec\-trust\-anchors\&.d/*\&.negative .PP /usr/lib/dnssec\-trust\-anchors\&.d/*\&.negative .SH BESCHREIBUNG .PP Die DNSSEC\-Vertrauensankerkonfigurationsdatei definiert positive und negative Vertrauensanker, auf denen \fBsystemd\-resolved.service\fP(8) DNSSEC\-Integritätsnachweise basieren\&. .SH "POSITIVE VERTRAUENSANKER" .PP Positive Vertrauensankerkonfigurationsdateien enthalten DNSKEY\- und DS\-Ressourcedatensatzdefinitionen, die als Basis für DNSSEC\-Integritätsnachweise genutzt werden\&. Siehe \m[blue]\fBRFC 4035, Abschnitt 4\&.4\fP\m[]\&\s-2\u[1]\d\s+2 für weitere Informationen über DNSSEC\-Vertrauensanker\&. .PP 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\&. .PP Positive Vertrauensankerdateien sind einfache Textdateien, die DNS\-Zonendateien ähneln, wie sie in \m[blue]\fBRFC 1035, Abschnitt 5\fP\m[]\&\s-2\u[2]\d\s+2 dokumentiert sind\&. Pro Zeile darf ein DS\- oder DNSKEY\-Ressourcendatensatz 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: .sp .if n \{\ .RS 4 .\} .nf \&. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 .fi .if n \{\ .RE .\} .PP 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 \m[blue]\fBRFC 4034,Abschnitt 5\fP\m[]\&\s-2\u[3]\d\s+2 für Details über die genaue Syntax und Bedeutung dieser Felder\&. .PP Alternativ dürfen DNSKEY\-Ressourcendatensätze verwandt werden, um Vertrauensanker, wie in dem nachfolgenden Beispiel, zu definieren: .sp .if n \{\ .RS 4 .\} .nf \&. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= .fi .if n \{\ .RE .\} .PP 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 \m[blue]\fBRFC 4034, Abschnitt 2\fP\m[]\&\s-2\u[4]\d\s+2 für Details über die genaue Syntax und Bedeutung dieser Felder\&. .PP 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\&. .PP 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\&. .PP Es wird im Allgemeinen empfohlen, Vertrauensanker in DS\-Ressourcendatensätzen statt in DNSKEY\-Ressourcendatensätzen zu kodieren\&. .PP 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 \m[blue]\fBRFC 5011\fP\m[]\&\s-2\u[5]\d\s+2 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\&. .PP Der aktuelle DNSSEC\-Vertrauensanker für die Wurzeldomain des Internets ist unter der Seite \m[blue]\fBIANA\-Vertrauensanker und \-Schlüssel\fP\m[]\&\s-2\u[6]\d\s+2 verfügbar\&. .SH "NEGATIVE VERTRAUENSANKER" .PP 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: .sp .if n \{\ .RS 4 .\} .nf # Inverse IPv4\-Abbildungen 10\&.in\-addr\&.arpa 16\&.172\&.in\-addr\&.arpa 168\&.192\&.in\-addr\&.arpa … # Einige angepasste Domains prod stag .fi .if n \{\ .RE .\} .PP Negative Vertrauensanker sind für private DNS\-Unterbäume nützlich, die nicht aus der Internet\-DNS\-Hierarchie referenziert und nicht signiert sind\&. .PP \m[blue]\fBRFC 7646\fP\m[]\&\s-2\u[7]\d\s+2 für Details über negative Vertrauensanker\&. .PP Falls keine negativen Vertrauensankerdateien konfiguriert sind, wird eine eingebaute Gruppe von gut bekannten privaten DNS\-Zone\-Domains als negative Vertrauensanker benutzt\&. .PP Es ist auch möglich, pro Schnittstelle negative Vertrauensanker zu definieren, indem die Einstellung \fIDNSSECNegativeTrustAnchors=\fP in \fBsystemd.network\fP(5)\-Dateien verwandt wird\&. .SH "SIEHE AUCH" .PP \fBsystemd\fP(1), \fBsystemd\-resolved.service\fP(8), \fBresolved.conf\fP(5), \fBsystemd.network\fP(5) .SH ANMERKUNGEN .IP " 1." 4 RFC 4035, Abschnitt 4.4 .RS 4 \%https://tools.ietf.org/html/rfc4035#section\-4.4 .RE .IP " 2." 4 RFC 1035, Abschnitt 5 .RS 4 \%https://tools.ietf.org/html/rfc1035#section\-5 .RE .IP " 3." 4 RFC 4034, Abschnitt 5 .RS 4 \%https://tools.ietf.org/html/rfc4034#section\-5 .RE .IP " 4." 4 RFC 4034, Abschnitt 2 .RS 4 \%https://tools.ietf.org/html/rfc4034#section\-2 .RE .IP " 5." 4 RFC 5011 .RS 4 \%https://tools.ietf.org/html/rfc5011 .RE .IP " 6." 4 IANA\-Vertrauensanker und \-Schlüssel .RS 4 \%https://data.iana.org/root\-anchors/root\-anchors.xml .RE .IP " 7." 4 RFC 7646 .RS 4 \%https://tools.ietf.org/html/rfc7646 .RE .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE 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 .MT debian-l10n-german@\:lists.\:debian.\:org Mailingliste der Übersetzer .ME .