diff --git a/nl_NL.ISO8859-1/articles/Makefile b/nl_NL.ISO8859-1/articles/Makefile
index f9ab224353..cff83ec0d1 100644
--- a/nl_NL.ISO8859-1/articles/Makefile
+++ b/nl_NL.ISO8859-1/articles/Makefile
@@ -1,7 +1,7 @@
# $FreeBSD$
# %SOURCE% en_US.ISO8859-1/articles/Makefile
-# %SRCID% 1.62
+# %SRCID% 1.63
SUBDIR =
SUBDIR+= contributing
diff --git a/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml
index de4ca3b64b..d2e096874c 100644
--- a/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml
+++ b/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml
@@ -1,11 +1,11 @@
<!--
The FreeBSD Dutch Documentation Project
- $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml,v 1.28 2011/05/15 04:11:45 rene Exp $
+ $FreeBSD$
Vertaald door: Siebrand Mazeland
%SOURCE% en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
- %SRCID% 1.208
+ %SRCID% 1.209
-->
<appendix id="eresources">
@@ -487,6 +487,12 @@
<entry>Discussies over netwerken en TCP/IP-broncode</entry>
</row>
+ <row>
+ <entry>&a.office.name;</entry>
+
+ <entry>Kantoortoepassingen op &os;</entry>
+ </row>
+
<row>
<entry>&a.openoffice.name;</entry>
@@ -1620,6 +1626,18 @@
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>&a.office.name;</term>
+
+ <listitem>
+ <para><emphasis>Kantoortoepassingen op &os;</emphasis></para>
+
+ <para>De discussie richt zich op kantoortoepassingen, hun
+ installatie, hun ontwikkeling en hun ondersteuning binnen
+ &os;.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>&a.openoffice.name;</term>
diff --git a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml
index 9e40d60cbf..870c8678b6 100644
--- a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml
+++ b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml
@@ -4,7 +4,7 @@
$FreeBSD$
%SOURCE% en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
- %SRCID% 1.130
+ %SRCID% 1.136
-->
<chapter id="network-servers">
@@ -4184,6 +4184,355 @@ mail IN A 192.168.1.5</programlisting>
zelf verzoeken in en onthoudt de antwoorden voor later gebruik.</para>
</sect2>
+ <sect2>
+ <title><acronym
+ role="Domain Name Security Extensions">DNSSEC</acronym></title>
+
+ <indexterm>
+ <primary>BIND</primary>
+
+ <secondary>DNS veiligheidsuitbreidingen</secondary>
+ </indexterm>
+
+ <para>Domain Name Security System Extentions, ofwel <acronym
+ role="Domain Name Security Extensions">DNSSEC</acronym>, is een
+ verzameling van specificaties om resolvende naamservers te beschermen
+ tegen valse <acronym>DNS</acronym>-gegevens, zoals vervalste
+ <acronym>DNS</acronym>-records. Door digitale handtekeningen te
+ gebruiken kan een resolver de integriteit van een record controleren.
+ Merk op dat <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
+ alleen integriteit biedt via het digitaal ondertekenen van het Resource
+ Record (<acronym role="Resource Record">RR</acronym>s). Het biedt noch
+ betrouwbaarheid noch bescherming tegen onjuiste aannames van
+ eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen
+ het bezoeken van <hostid role="domainname">voorbeeld.net</hostid> in
+ plaats van <hostid role="domainname">voorbeeld.com</hostid>. Het enige
+ wat <acronym>DNSSEC</acronym> doet is authenticeren dat de gegevens
+ niet tijdens het transport zijn gecompromitteerd. De beveiliging van
+ <acronym>DNSSEC</acronym> is een belangrijke stap in het beveiligen van
+ het internet in het algemeen. De relevante <acronym>RFC</acronym>s zijn
+ een goed beginpunt voor meer gedetailleerde gegevens over hoe
+ <acronym>DNSSEC</acronym> werkt. Raadpleeg de lijst in
+ <xref linkend="dns-read">.</para>
+
+ <para>De volgende secties laten zien hoe <acronym>DNSSEC</acronym> voor een
+ autoratieve <acronym>DNS</acronym>-server en een recursieve (of caching)
+ <acronym>DNS</acronym>-server die <acronym>BIND</acronym> 9 draait kan
+ worden bewerkstelligd. Hoewel alle versies van <acronym>BIND</acronym>
+ 9 <acronym>DNSSEC</acronym> ondersteunen, is tenminste versie 9.6.2
+ nodig om gebruik te kunnen maken van de ondertekende rootzones tijdens
+ het valideren van <acronym>DNS</acronym>-verzoeken. Dit komt doordat
+ eerdere versies de benodigde algoritmes om validatie met de sleutel
+ voor de rootzone te uit te voeren niet hebben. Het wordt sterk
+ aangeraden om de nieuwste versie van <acronym>BIND</acronym> 9.7 te
+ gebruiken om gebruik te kunnen maken van automatische sleutel-updates
+ voor de rootsleutel en van andere mogelijkheden om zones ondertekend en
+ sleutel up-to-date te houden. Wanneer configuraties tussen 9.6.2 en 9.7
+ en later verschillen, zullen deze worden toegelicht.</para>
+
+ <sect3>
+ <title>Configuratie van een recursieve
+ <acronym>DNS</acronym>-server</title>
+
+ <para>Het aanzetten van <acronym>DNSSEC</acronym>-validatie van
+ verzoeken die door een recursieve <acronym>DNS</acronym>-server worden
+ uitgevoerd heeft enkele aanpassingen aan
+ <filename>named.conf</filename> nodig. Voordat deze wijzigingen
+ worden worden gemaakt dient de rootzone-sleutel, of vertrouwensanker,
+ worden opgehaald. Momenteel is de rootzone-sleutel niet beschikbaar
+ in een bestandsformaat dat <acronym>BIND</acronym> begrijpt, dus moet
+ het handmatig in het juiste formaat omgezet worden. De sleutel zelf
+ kan verkregen worden door de rootzone ervoor met
+ <application>dig</application> te ondervragen. Door</para>
+
+ <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . > root.dnskey</userinput></screen>
+
+ <para>te draaien, wordt de sleutel in <filename>root.dnskey</filename>
+ opgeslagen. De inhoud dient er ongeveer als volgt uit te zien:</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>Schrik niet als de verkregen sleutels anders zijn dan in dit
+ voorbeeld. Ze kunnen zijn veranderd nadat deze instructies voor het
+ laatst waren bijgewerkt. De uitvoer bevat in feite twee sleutels. De
+ eerste sleutel, met de waarde 257 na het DNSKEY-recordtype, is degene
+ die nodig is. Deze waarde geeft aan dat dit een Secure Entry Point (
+ <acronym role="Secure Entry Point">SEP</acronym>) is, beter bekend als
+ een Key Signing Key (<acronym role="Key Signing Key">KSK</acronym>).
+ De tweede sleutel, met de waarde 256, is een deelsleutel, beter bekend
+ als een Zone Signing Key (<acronym
+ role="Zone Signing Key">ZSK</acronym>). Meer over de verschillende
+ soorten sleutels komt aan bod in <xref
+ linkend="dns-dnssec-auth">.</para>
+
+ <para>Nu moet de sleutel gecontroleerd en geformatteerd worden zodat
+ <acronym>BIND</acronym> deze kan gebruiken. Maak om de sleutel te
+ controleren een <acronym role="Delegation Signer">DS</acronym> -
+ <acronym role="Resource Record">RR</acronym>-paar aan. Maak een
+ bestand aan dat deze <acronym role="Resource Record">RR</acronym>s
+ bevat aan met</para>
+
+ <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . > root.ds</userinput></screen>
+
+ <para>Deze records gebruiken respectievelijk SHA-1 en SHA-256, en dienen
+ er als het volgende voorbeeld uit te zien, waarbij het langere record
+ SHA-256 gebruikt.</para>
+
+ <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
+. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
+
+ <para>Het SHA-256 <acronym>RR</acronym> kan nu worden vergeleken met de
+ digest in <ulink
+ url="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</ulink>.
+ Om er absoluut zeker van te zijn dat er niet geknoeid is met de
+ sleutel kunnen de gegevens in het <acronym>XML</acronym>-bestand
+ worden gecontroleerd met de <acronym>PGP</acronym>-handtekening in
+ <ulink url="https://data.iana.org/root-anchors/root-anchors.asc">https//data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
+
+ <para>Vervolgens dient de sleutel juist geformateerd te worden. Dit
+ verschilt een beetje tussen versie 9.6.2 en versie 9.7 en later van
+ <acronym>BIND</acronym>. In versie 9.7 is ondersteuning toegevoegd om
+ automatisch veranderingen aan de sleutel te volgen en deze bij te
+ werken indien nodig. Dit wordt gedaan met
+ <literal>managed-keys</literal> zoals in het volgende voorbeeld te
+ zien is. Als de oudere versie gebruikt wordt, wordt de sleutel
+ toegevoegd met een commando <literal>trusted-keys</literal> en dient
+ deze handmatig bijgewerkt te worden. Voor <acronym>BIND</acronym>
+ 9.6.2 ziet het formaat er uit als:</para>
+
+ <programlisting>trusted-keys {
+ "." 257 3 8
+ "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+ FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+ bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+ X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+ W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+ Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+ QxA+Uk1ihz0=";
+};</programlisting>
+
+ <para>Voor versie 9.7 ziet het formaat er echter zo uit:</para>
+
+ <programlisting>managed-keys {
+ "." initial-key 257 3 8
+ "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+ FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+ bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+ X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+ W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+ Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+ QxA+Uk1ihz0=";
+};</programlisting>
+
+ <para>De rootsleutel kan nu aan <filename>named.conf</filename> worden
+ toegevoegd, ofwel direct of door een bestand dat de sleutel bevat te
+ includen. Stel na deze stappen <acronym>BIND</acronym> in zodat het
+ <acronym>DNSSEC</acronym>-validatie uitvoert op verzoeken door
+ <filename>named.conf</filename> te bewerken en het volgende aan de
+ directief <literal>options</literal> toe te voegen:</para>
+
+ <programlisting>dnssec-enable yes;
+dnssec-validation yes;</programlisting>
+
+ <para>Om te controleren dat het ook echt werkt, kan
+ <application>dig</application> gebruikt worden om een verzoek op een
+ ondertekende zone uit te voeren met de zojuist geconfigureerde
+ resolver. Een succesvol antwoord zal de vlag <literal>AD</literal>
+ bevatten om aan te geven dat de gegevens zijn geautenticeerd. Een
+ verzoek als</para>
+
+ <screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
+
+ <para>zou het <acronym>DS</acronym> <acronym>RR</acronym> paar voor de
+ <literal>.se</literal>-zone moeten teruggeven. In de sectie
+ <literal>flags:</literal> moet de vlag <literal>AD</literal> te zien
+ zijn, als in:</para>
+
+ <programlisting>...
+;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
+...</programlisting>
+
+ <para>De resolver is nu in staat om <acronym>DNS</acronym>-verzoeken te
+ autenticeren.</para>
+ </sect3>
+
+ <sect3 id="dns-dnssec-auth">
+ <title>Configuratie van een autoratieve
+ <acronym>DNS</acronym>-server</title>
+
+ <para>Om een autoratieve naamserver een met <acronym>DNSSEC</acronym>
+ ondertekende zone te laten serveren is wat meer werk nodig. Een zone
+ wordt ondertekend met cryptografische sleutels die aangemaakt moeten
+ worden. Het is mogelijk om hier slechts één sleutel
+ voor te gebruiken. De methode die de voorkeur verdient is echter om
+ een sterke, goed beschermde Key Signing Key (<acronym
+ role="Key Signing Key">KSK</acronym>) die niet vaak wordt geroteerd
+ en een Zone Signing Key (<acronym
+ role="Zone Signing Key">ZSK</acronym>) die vaker wordt geroteerd te
+ hebben. Informatie over aanbevolen procedures staat in <ulink
+ url="http://tools.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>
+ 4641: <acronym>DNSSEC</acronym> Operational Practices</ulink>.
+ Procedures betreffende de rootzone staan in <ulink
+ url="http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt"><acronym>DNSSEC</acronym>
+ Practice Statement for the Root Zone <acronym>KSK</acronym>
+ operator</ulink> en <ulink url="http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt"><acronym>DNSSEC</acronym>
+ Practice Statement for the Root Zone <acronym>ZSK</acronym>
+ operator</ulink>. De <acronym role="Key Signing Key">KSK</acronym>
+ wordt gebruikt om een autoriteitsketen voor de te valideren gegevens
+ op te bouwen en wordt daarom ook een Secure Entry Point (<acronym
+ role="Secure Entry Point">SEP</acronym>)-sleutel genoemd. Een
+ bericht-digest van deze sleutel, dat Delegation Signer (<acronym
+ role="Delegation Signer">DS</acronym>)-record genoemd wordt, moet
+ gepubliceerd zijn in de ouderzone om een vertrouwensketen op te
+ bouwen. Hoe dit bereikt wordt hangt af van de eigenaar van de
+ ouderzone. De <acronym role="Zone Signing Key">ZSK</acronym> wordt
+ gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd
+ te worden.</para>
+
+ <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>Onderteken tenslotte 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
+ uit moeten zien:</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>-hiërarchie
+ 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>
+
<sect2>
<title>Beveiliging</title>
@@ -4210,11 +4559,12 @@ mail IN A 192.168.1.5</programlisting>
</tip>
</sect2>
- <sect2>
+ <sect2 id="dns-read">
<title>Verder lezen</title>
<para>BIND/<application>named</application> hulppagina's:
- &man.rndc.8;, &man.named.8;, &man.named.conf.5;</para>
+ &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8;
+ &man.dnssec-signzone.8; &man.dnssec-keygen.8;</para>
<itemizedlist>
<listitem>
@@ -4233,16 +4583,54 @@ mail IN A 192.168.1.5</programlisting>
<para><ulink
url="http://www.oreilly.com/catalog/dns5/">O'Reilly DNS en
BIND 5e Editie</ulink></para>
+ </listitem>
+
<listitem>
- <para><ulink
- url="http://tools.ietf.org/rfc/html/rfc1034">RFC1034 -
- Domeinnamen - Concepten en Faciliteiten</ulink></para>
+ <para><ulink url="http://www.root-dnssec.org/documentation/">Root
+ <acronym>DNSSEC</acronym></ulink></para>
</listitem>
<listitem>
<para><ulink
- url="http://tools.ietf.org/rfc/html/rfc1035">RFC1035 -
- Domeinnamen - Implementatie en Specificatie</ulink></para>
+ url="http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html">
+ <acronym>DNSSEC</acronym> Trust Anchor Publication for the Root
+ Zone</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc1034">RFC1034 -
+ Domain Names - Concepts and Facilitities</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc1035">RFC1035 -
+ Domain Names - Implementation and Specification</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc4033">RFC4033 -
+ DNS Security Introduction and Requirements</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc4034">RFC4034 -
+ Resource Records for the DNS Security Extensions</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc4035">RFC4035 -
+ Protocol Modifications for the DNS Security Extensions</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc4641">RFC4641 -
+ DNSSEC Operational Practices</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://tools.ietf.org/html/rfc5011">RFC5011 -
+ Automated Updates of DNS Security (<acronym>DNSSEC</acronym> Trust
+ Anchors)</ulink></para>
</listitem>
</itemizedlist>
</sect2>
diff --git a/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent b/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent
index 907c4d150e..1f7d870323 100644
--- a/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent
+++ b/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent
@@ -1,11 +1,11 @@
<!--
Namen van FreeBSD mailinglijsten en gerelateerde software.
- $FreeBSD: doc/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent,v 1.24 2011/05/11 18:58:09 rene Exp $
+ $FreeBSD$
Vertaald door: Siebrand Mazeland
%SOURCE% en_US.ISO8859-1/share/sgml/mailing-lists.ent
- %SRCID% 1.79
+ %SRCID% 1.80
-->
<!ENTITY a.mailman.listinfo "http://lists.FreeBSD.org/mailman/listinfo">
@@ -311,6 +311,10 @@
<!ENTITY a.newbus "<ulink url='&a.newbus.url;'>&os; new-bus mailinglijst</ulink>">
<!ENTITY a.newbus.name "<ulink url='&a.newbus.url;'>freebsd-new-bus</ulink>">
+<!ENTITY a.office.url "&a.mailman.listinfo;/freebsd-office">
+<!ENTITY a.office "<ulink url='&a.office.url;'>Kantoortoepassingen op &os;</ulink>">
+<!ENTITY a.office.name "<ulink url='&a.office.url;'>freebsd-office</ulink>">
+
<!ENTITY a.openoffice.url "&a.mailman.listinfo;/freebsd-openoffice">
<!ENTITY a.openoffice "<ulink url='&a.openoffice.url;'>&os; OpenOffice mailinglijst</ulink>">
<!ENTITY a.openoffice.name "<ulink url='&a.openoffice.url;'>freebsd-openoffice</ulink>">