From owner-p4-projects@FreeBSD.ORG Tue Jul 19 21:32:36 2011 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id BB8B11065672; Tue, 19 Jul 2011 21:32:36 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1AB106566B for ; Tue, 19 Jul 2011 21:32:36 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB7E8FC14 for ; Tue, 19 Jul 2011 21:32:36 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id p6JLWa37091979 for ; Tue, 19 Jul 2011 21:32:36 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id p6JLWaxs091976 for perforce@freebsd.org; Tue, 19 Jul 2011 21:32:36 GMT (envelope-from rene@FreeBSD.org) Date: Tue, 19 Jul 2011 21:32:36 GMT Message-Id: <201107192132.p6JLWaxs091976@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 196415 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:32:37 -0000 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 ZSK wordt gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd te worden. - + + Om DNSSEC aan te zetten voor de zone voorbeeld.com zoals beschreven in de + voorgaande voorbeelden, dient als eerste + dnssec-keygen gebruikt te worden om het + sleutelpaar met de KSK en ZSK + 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 KSK voor voorbeeld.com te genereren: + + &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE voorbeeld.com + + en om de ZSK te genereren: + + &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE voorbeeld.com + + dnssec-keygen maakt twee bestanden, de + publieke en private sleutels in bestanden met namen als + Kvoorbeeld.com.+005+nnnnn.key (publiek) en + Kvoorbeeld.com.+005+nnnnn.private (privaat). Het + gedeelte nnnnn 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 KSK-bestand: + + &prompt.user; mv Kvoorbeeld.com+005+nnnnn.key Kvoorbeeld.com+005+nnnn.KSK.key +&prompt.user; mv Kvoorbeeld.com+005+nnnnn.private Kvoorbeeld.com+005+nnnnn.KSK.private + + Voor ZSK-bestanden dient KSK + waar nodig door ZSK vervangen te worden. De + bestanden kunnen nu worden opgenomen in het zonebestand, door de + opdracht $include te gebruiken. Het zou er + ongeveer als volgt uit moeten zien: + + + $include Kvoorbeeld.com.+005+nnnnn.KSK.key ; KSK +$include Kvoorbeeld.com.+005+nnnnn.ZSK.key ; ZSK + + Tenslotte, onderteken de zone en vertel BIND om + het ondertekende zonebestand te gebruiken. Voor het ondertekenen van + een zone wordt dnssec-signzone gebruikt. + Het commando om de zone voorbeeld.com, dat zich in + voorbeeld.com.db bevindt, zou er ongeveer zo + uitzien: + + &prompt.user; dnssec-signzone -o voorbeeld.com -k Kvoorbeeld.com+005+nnnnn.KSK voorbeeld.com.db Kvoorbeeld.com+005+nnnnn.ZSK.key + + De sleutel die aan het argument wordt + meegegeven is de KSK en het andere sleutelbestand + is de ZSK dat bij het ondertekenen gebruikt moet + worden. Het is mogelijk om meer dan één + KSK en ZSK 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 + dnssec-signzone is een zonebestand met + daarin alle RRs ondertekend. Deze uitvoer komt in + een bestand met de extensie .signed terecht, zoals + voorbeeld.com.db.signed. De DS-records worden ook naar een + apart bestand dsset-voorbeeld.com geschreven. Om + deze ondertekende zone te gebruiken hoeft alleen de zone-directief in + named.conf veranderd te worden om + voorbeeld.com.db.signed. 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. + + 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 DNS-gegevens tijdelijk onbeschikbaar zijn totdat de nieuwe sleutel door de DNS-hierarchie is + gepropageerd. Meer informatie over sleutelwisselingen en andere + praktijken rondom DNSSEC staan in RFC + 4641: DNSSEC Operational practices. + + + + Automatisering met <acronym>BIND</acronym> 9.7 of nieuwer + + In versie 9.7 van BIND is een nieuwe + mogelijkheid genaamd Smart Signing + 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 + sleutelreservoir te stoppen en de nieuwe optie + auto-dnssec 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 + nsupdate met de nieuwe . + rndc kan nu ook zones ondertekenen met + sleutels uit het sleutelreservoir door de optie + te gebruiken. Voeg, om BIND dit automatische + ondertekenen en bijwerken van zones te laten gebruiken voor voorbeeld.com, het volgende aan + named.conf toe: + + zone voorbeeld.com { + type master; + key-directory "/etc/named/keys"; + update-policy local; + auto-dnssec maintain; + file "/etc/named/dynamic/voorbeeld.com.zone"; +}; + + Nadat deze veranderingen gemaakt zijn, dienen de sleutels voor de + zone aangemaakt te worden zoals uitgelegd in , deze sleutels in het sleutelreservoir + gestopt te worden dat als argument aan de + key-directory in het zoneconfiguratie is + meegegeven, waarna de zone automatisch zal worden ondertekend. Zones + die op deze manier zijn geconfigureerd dienen met + nsupdate te worden gedaan, dat voor het + opnieuw ondertekenen van de zone met de nieuw toegevoegde gegevens zal + zorgen. Zie voor meer details en de + BIND-documentatie.