© 1995-2011 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
bcr 2011-10-16 12:19:17 UTC
FreeBSD German Documentation Repository
Modified files:
books/handbook/network-servers chapter.sgml
Log:
MFen 1.132:
Neuen Abschnitt, der von DNSSEC handelt, eingebaut.
Revision Changes Path
1.98 +466 -12 de-docproj/books/handbook/network-servers/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/handbook/network-servers/chapter.sgml,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -I$FreeBSDde.*$ -r1.97 -r1.98
--- chapter.sgml 15 Oct 2011 20:03:05 -0000 1.97
+++ chapter.sgml 16 Oct 2011 12:19:16 -0000 1.98
@@ -3,8 +3,8 @@
The FreeBSD German Documentation Project
$FreeBSD$
- $FreeBSDde: de-docproj/books/handbook/network-servers/chapter.sgml,v 1.97 2011/10/15 20:03:05 bcr Exp $
- basiert auf: 1.131
+ $FreeBSDde: de-docproj/books/handbook/network-servers/chapter.sgml,v 1.98 2011/10/16 12:19:16 bcr Exp $
+ basiert auf: 1.132
-->
<chapter id="network-servers">
@@ -4229,6 +4229,422 @@
eigene Anfragen und speichert deren Ergebnisse ab.</para>
</sect2>
+ <sect2>
+ <title><acronym
+ role="Doman Name Security Extensions">DNSSEC</acronym></title>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>DNS security extensions</secondary>
+ </indexterm>
+
+ <para>Domain Name System Security Extensions, oder kurz <acronym
+ role="Domain Name Security Extensions">DNSSEC</acronym>, ist eine
+ Sammlung von Spezifikationen, um auflösende Nameserver von
+ gefälschten <acronym>DNS</acronym>-Daten, wie beispielsweise
+ vorgetäuschte <acronym>DNS</acronym>-Einträge, zu
+ schützen. Durch die Verwendung von digitalen Signaturen kann
+ ein Resolver die Integrität des Eintrages
+ überprüfen. Wichtig dabei ist, dass <acronym
+ role="Domain Name Security Extensions">DNSSEC</acronym> nur die
+ Integrität über digital signierte Resource Records
+ (<acronym role="Resource Record">RR</acronym>e) bereitstellt.
+ Weder wird die Vertraulichkeit noch der Schutz vor falschen
+ Annahmen des Endbenutzers sichergestellt. Dies bedeutet, dass es
+ Leute nicht davor schützen kann, die zu <hostid
+ role="domainname">example.net</hostid> anstatt zu <hostid
+ role="domainname">example.com</hostid> gelangen möchten. Das
+ einzige, was <acronym>DNSSEC</acronym> tut, ist die
+ Authentifizierung, dass die Daten während der
+ Übertragung nicht verändert wurden. Die Sicherheit von
+ <acronym>DNS</acronym> ist ein wichtiger Schritt in der
+ generellen Absicherung des Internets. Für weitere,
+ tiefergehende Details über die Funktionsweise von
+ <acronym>DNSSEC</acronym> sind die dazugehörigen
+ <acronym>RFC</acronym>s ein guter Einstieg in die Thematik. Sehen
+ Sie sich dazu die Liste in <xref linkend="dns-read"> an.</para>
+
+ <para>Der folgende Abschnitt wird zeigen, wie man
+ <acronym>DNSSEC</acronym> für einen autoritativen
+ <acronym>DNS</acronym>-Server und einen rekursiven (oder cachenden)
+ <acronym>DNS</acronym>-Server, der jeweils
+ <acronym>BIND</acronym> 9 verwenden, einrichten kann. Obwohl alle
+ Versionen von <acronym>BIND</acronym> 9 <acronym>DNSSEC</acronym>
+ unterstützen, ist es notwendig, mindestens die Version 9.6.2
+ zu verwenden, um in der Lage zu sein, die signierten Root-Zonen zu
+ benutzen, wenn <acronym>DNS</acronym>-Abfragen geprüft
+ werden. Der Grund dafür ist, dass früheren Versionen
+ die Algorithmen fehlen, um die Überprüfung des
+ Root-Zonenschlüssels zu aktivieren. Es wird sehr empfohlen,
+ die letzte Version von <acronym>BIND</acronym> 9.7 oder höher
+ einzusetzen, um von den Vorteilen der automatischen
+ Schlüsselaktualisierung des Root-Zonenschlüssels
+ Gebrauch zu machen, genauso wie andere Eigenschaften, um
+ automatisch Zonen signieren zu lassen und Signaturen aktuell zu
+ halten. Unterschiede zwischen den Versionen 9.6.2 und 9.7 und
+ höher werden an den betreffenden Stellen angesprochen.</para>
+
+ <sect3>
+ <title>Rekursive <acronym>DNS</acronym>-Server Konfiguration</title>
+
+ <para>Die Aktivierung der
+ <acronym>DNSSEC</acronym>-Überprüfung von Anfragen,
+ die von einem rekursiven <acronym>DNS</acronym>-Server
+ stammen, benötigt ein paar Änderungen in der
+ <filename>named.conf</filename>. Bevor man jedoch diese
+ Änderungen durchführt, muss der
+ Root-Zonenschlüssel oder Vertrauensanker erworben werden.
+ Momentan ist der Root-Zonenschlüssel nicht in einem
+ Dateiformat verfügbar, dass von <acronym>BIND</acronym>
+ benutzt werden kann, so dass dieser manuell in das richtige
+ Format konvertiert werden muss. Der Schlüssel selbst kann
+ durch Abfrage an die Root-Zone erhalten werden, indem man dazu
+ <application>dig</application> verwendet. Durch Aufruf
+ von</para>
+
+ <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . > root.dnskey</userinput></screen>
+
+ <para>wird der Schlüssel in
+ <filename>root.dnskey</filename> abgelegt. Der Inhalt sollte
+ so ähnlich wie folgt aussehen:</para>
+
+ <programlisting>. 93910 IN DNSKEY 257 3 8 (
+ AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
+ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
+ /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
+ JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
+ oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
+ LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
+ Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
+ LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
+ ) ; key id = 19036
+. 93910 IN DNSKEY 256 3 8 (
+ AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
+ UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
+ g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
+ EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
+) ; key id = 34525</programlisting>
+
+ <para>Seien Sie nicht alarmiert, wenn der von Ihnen bezogene
+ Schlüssel anders als in diesem Beispiel aussieht. Diese
+ könnten sich in der Zwischenzeit geändert haben. In
+ dieser Ausgabe sind eigentlich zwei Schlüssel enthalten.
+ Der erste Schüssel mit dem Wert 257 nach dem
+ DNSKEY-Eintrag ist derjenige, der benötigt wird. Der
+ Wert zeigt an, dass es sich um einen sicheren Einstiegspunkt
+ (<acronym role="Secure Entry Point">SEP</acronym>), gemein
+ auch als Schlüsselsignierungsschlüssel (<acronym
+ role="Key Signing Key">KSK</acronym>) bekannt, handelt. Der
+ zweite Schüssel mit dem Wert 256 ist der untergeordnete
+ Schlüssel, im allgemeinen auch als
+ Zonen-Signaturschlüssel (<acronym
+ role="Zone Signing Key">ZSK</acronym>) bezeichnet. Weitere
+ Schlüsselarten werden später in <xref
+ linkend="dns-dnssec-auth"> erläutert.</para>
+
+ <para>Nun muss der Schlüssel verifiziert und so formatiert
+ werden, dass <acronym>BIND</acronym> diesen verwenden kann.
+ Um den Schlüssel zu verfizieren, erzeugen Sie einen
+ <acronym role="Delegation Signer">DS</acronym> <acronym
+ role="Resource Record">RR</acronym>-Satz. Erstellen Sie eine
+ Datei, welche die <acronym
+ role="Resource Record">RR</acronym>s enthält,
+ mittels</para>
+
+ <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . > root.ds</userinput></screen>
+
+ <para>Diese Einträge verwenden SHA-1 sowie SHA-256 und
+ sollten ähnlich zu folgendem Beispiel aussehen, in dem
+ der längere, SHA-256, benutzt wird.</para>
+
+ <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
+. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
+
+ <para>Der SHA-256 <acronym>RR</acronym> kann nun mit dem Abriss
+ in <ulink
+ url="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</ulink> verglichen werden. Um
+ absolut sicher zu sein, dass der Schlüssel nicht
+ zusammen mit den <acronym>XML</acronym>-Daten verändert
+ wurde, kann die Datei mittels der <acronym>PGP</acronym>
+ Signatur in <ulink
+ url="https://data.iana.org/root-anchors/root-anchors.asc">https://data.iana.org/root-anchors/root-anchors.asc</ulink> überprüft werden.</para>
+
+ <para>Als nächstes muss der Schlüssel in das passende
+ Format gebracht werden. Dies unterscheidet sich ein bisschen
+ von den <acronym>BIND</acronym> Versionen 9.6.2 und 9.7 und
+ höhere. In version 9.7 wurde die Ünterstützung
+ zur automatischen Verfolgung und notwendigen Aktualisierung
+ von Änderungen am Schlüssel eingebaut. Dies wird
+ durch den Einsatz von <literal>managed-keys</literal>
+ erreicht, wie in dem Beispiel unten gezeigt ist. Wenn die
+ ältere Version eingesetzt wird, kann der Schlüssel
+ durch eine <literal>trusted-keys</literal>-Anweisung eingebaut
+ werden und die Aktualisierung muss händisch erfolgen.
+ In <acronym>BIND</acronym> 9.6.2 sollte das Format
+ folgendermassen aussehen:</para>
+
+ <programlisting>trusted-keys {
+ "." 257 3 8
+ "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+ FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+ bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+ X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+ W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+ Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+ QxA+Uk1ihz0=";
+};</programlisting>
+
+ <para>In 9.7 wird das Format stattdessen wie folgt
+ aussehen:</para>
+
+ <programlisting>managed-keys {
+ "." initial-key 257 3 8
+ "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+ FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+ bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+ X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+ W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+ Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+ QxA+Uk1ihz0=";
+};</programlisting>
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Sun 16 Oct 2011 - 14:19:37 CEST