Date: Tue, 19 Jul 2011 21:32:36 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 196415 for review Message-ID: <201107192132.p6JLWaxs091976@skunkworks.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://p4web.freebsd.org/@@196415?ac=10 Change 196415 by rene@rene_acer on 2011/07/19 21:31:43 Finish raw translation of network-servers update, still needs spell and sanity/consistency check. Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#44 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#44 (text+ko) ==== @@ -4403,7 +4403,132 @@ ouderzone. De <acronym role="Zone Signing Key">ZSK</acronym> wordt gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd te worden.</para> -<!--rene hier--> + + <para>Om <acronym>DNSSEC</acronym> aan te zetten voor de zone <hostid + role="domainname">voorbeeld.com</hostid> zoals beschreven in de + voorgaande voorbeelden, dient als eerste + <application>dnssec-keygen</application> gebruikt te worden om het + sleutelpaar met de <acronym>KSK</acronym> en <acronym>ZSK</acronym> + te genereren. Dit sleutelpaar kan verschillende cryptografische + algoritmes gebruiken. Het wordt aanbevolen om RSA/SHA-256 voor de + sleutels te gebruiken, een sleutellengte van 2048 bits zou voldoende + moeten zijn. Om de <acronym>KSK</acronym> voor <hostid + role="domainname">voorbeeld.com</hostid> te genereren:</para> + + <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE voorbeeld.com</userinput></screen> + + <para>en om de <acronym>ZSK</acronym> te genereren:</para> + + <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE voorbeeld.com</userinput></screen> + + <para><application>dnssec-keygen</application> maakt twee bestanden, de + publieke en private sleutels in bestanden met namen als + <filename>Kvoorbeeld.com.+005+nnnnn.key</filename> (publiek) en + <filename>Kvoorbeeld.com.+005+nnnnn.private</filename> (privaat). Het + gedeelte <literal>nnnnn</literal> van de bestandsnaam is een + sleutel-ID van vijf cijfers. Houd bij welke sleutel-ID bij welke + sleutel hoort. Dit is in het bijzonder van belang wanneer er meerdere + sleutels per zone zijn. Het is ook mogelijk om de sleutels te + hernoemen. Voor elk <acronym>KSK</acronym>-bestand:</para> + + <screen>&prompt.user; <userinput>mv Kvoorbeeld.com+005+nnnnn.key Kvoorbeeld.com+005+nnnn.KSK.key</userinput> +&prompt.user; <userinput>mv Kvoorbeeld.com+005+nnnnn.private Kvoorbeeld.com+005+nnnnn.KSK.private</userinput></screen> + + <para>Voor <acronym>ZSK</acronym>-bestanden dient <literal>KSK</literal> + waar nodig door <literal>ZSK</literal> vervangen te worden. De + bestanden kunnen nu worden opgenomen in het zonebestand, door de + opdracht <literal>$include</literal> te gebruiken. Het zou er + ongeveer als volgt uit moeten zien:</para> + + + <programlisting>$include Kvoorbeeld.com.+005+nnnnn.KSK.key ; KSK +$include Kvoorbeeld.com.+005+nnnnn.ZSK.key ; ZSK</programlisting> + + <para>Tenslotte, onderteken de zone en vertel <acronym>BIND</acronym> om + het ondertekende zonebestand te gebruiken. Voor het ondertekenen van + een zone wordt <application>dnssec-signzone</application> gebruikt. + Het commando om de zone <hostid + role="domainname">voorbeeld.com</hostid>, dat zich in + <filename>voorbeeld.com.db</filename> bevindt, zou er ongeveer zo + uitzien:</para> + + <screen>&prompt.user; <userinput>dnssec-signzone -o voorbeeld.com -k Kvoorbeeld.com+005+nnnnn.KSK voorbeeld.com.db Kvoorbeeld.com+005+nnnnn.ZSK.key</userinput></screen> + + <para>De sleutel die aan het argument <option>-k</option> wordt + meegegeven is de <acronym>KSK</acronym> en het andere sleutelbestand + is de <acronym>ZSK</acronym> dat bij het ondertekenen gebruikt moet + worden. Het is mogelijk om meer dan één + <acronym>KSK</acronym> en <acronym>ZSK</acronym> op te geven, wat tot + gevolg heeft dat de zone met alle meegegeven sleutels wordt + ondertekend. Dit kan nodig zijn om zonegegevens aan te leveren die + met meerdere algoritmes zijn ondertekend. De uitvoer van + <application>dnssec-signzone</application> is een zonebestand met + daarin alle <acronym>RR</acronym>s ondertekend. Deze uitvoer komt in + een bestand met de extensie <literal>.signed</literal> terecht, zoals + <filename>voorbeeld.com.db.signed</filename>. De <acronym + role="Delegation Signer">DS</acronym>-records worden ook naar een + apart bestand <filename>dsset-voorbeeld.com</filename> geschreven. Om + deze ondertekende zone te gebruiken hoeft alleen de zone-directief in + <filename>named.conf</filename> veranderd te worden om + <filename>voorbeeld.com.db.signed</filename>. Standaard zijn de + ondertekeningen slechts 30 dagen geldig, wat betekent dat de zone over + ongeveer 15 dagen hertekend moet worden om er zeker van te zijn dat + resolvers geen records met oude ondertekeningen cachen. Het is + mogelijk om hiervoor een script en een crontaak te maken. Bekijk de + relevante handleidingen voor details.</para> + + <para>Zorg ervoor dat de private sleutels veilig blijven, zoals met alle + cryptografische sleutels. Bij het veranderen van een sleutel is het + het beste om de nieuwe sleutel in de zone op te nemen, en nog met de + oude sleutel te ondertekenen, en om daarna over te stappen op de + nieuwe sleutel. Nadat deze handelingen zijn voltooid kan de oude + sleutel uit de zone worden verwijderd. Wanneer dit niet wordt gedaan + kunnen de <acronym>DNS</acronym>-gegevens tijdelijk onbeschikbaar zijn totdat de nieuwe sleutel door de <acronym>DNS</acronym>-hierarchie is + gepropageerd. Meer informatie over sleutelwisselingen en andere + praktijken rondom <acronym>DNSSEC</acronym> staan in <ulink + url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>; + 4641: <acronym>DNSSEC</acronym> Operational practices</ulink>.</para> + </sect3> + + <sect3> + <title>Automatisering met <acronym>BIND</acronym> 9.7 of nieuwer</title> + + <para>In versie 9.7 van <acronym>BIND</acronym> is een nieuwe + mogelijkheid genaamd <emphasis>Smart Signing</emphasis> + geïntroduceerd. Deze mogelijkheid heeft als doel om het + sleutelbeheer en ondertekenproces eenvoudiger te maken door delen van + deze taken te automatiseren. Door de sleutels in een + <emphasis>sleutelreservoir</emphasis> te stoppen en de nieuwe optie + <literal>auto-dnssec</literal> te gebruiken, is het mogelijk om een + dynamische zone aan te maken welke opnieuw getekend wordt indien dat + nodig is. Gebruik om deze zone bij te werken + <application>nsupdate</application> met de nieuwe <option>-l</option>. + <application>rndc</application> kan nu ook zones ondertekenen met + sleutels uit het sleutelreservoir door de optie <option>sign</option> + te gebruiken. Voeg, om <acronym>BIND</acronym> dit automatische + ondertekenen en bijwerken van zones te laten gebruiken voor <hostid + role="domainname">voorbeeld.com</hostid>, het volgende aan + <filename>named.conf</filename> toe:</para> + + <programlisting>zone voorbeeld.com { + type master; + key-directory "/etc/named/keys"; + update-policy local; + auto-dnssec maintain; + file "/etc/named/dynamic/voorbeeld.com.zone"; +};</programlisting> + + <para>Nadat deze veranderingen gemaakt zijn, dienen de sleutels voor de + zone aangemaakt te worden zoals uitgelegd in <xref + linkend="dns-dnssec-auth">, deze sleutels in het sleutelreservoir + gestopt te worden dat als argument aan de + <literal>key-directory</literal> in het zoneconfiguratie is + meegegeven, waarna de zone automatisch zal worden ondertekend. Zones + die op deze manier zijn geconfigureerd dienen met + <application>nsupdate</application> te worden gedaan, dat voor het + opnieuw ondertekenen van de zone met de nieuw toegevoegde gegevens zal + zorgen. Zie voor meer details <xref linkend="dns-read"> en de + <acronym>BIND</acronym>-documentatie.</para> </sect3> </sect2>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107192132.p6JLWaxs091976>