From owner-p4-projects@FreeBSD.ORG Fri Jul 22 20:07:43 2011 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 5F0041065675; Fri, 22 Jul 2011 20:07:43 +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 083A91065670 for ; Fri, 22 Jul 2011 20:07:43 +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 E94EA8FC14 for ; Fri, 22 Jul 2011 20:07:42 +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 p6MK7gc3051290 for ; Fri, 22 Jul 2011 20:07:42 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id p6MK7gGR051287 for perforce@freebsd.org; Fri, 22 Jul 2011 20:07:42 GMT (envelope-from rene@FreeBSD.org) Date: Fri, 22 Jul 2011 20:07:42 GMT Message-Id: <201107222007.p6MK7gGR051287@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 196561 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: Fri, 22 Jul 2011 20:07:43 -0000 http://p4web.freebsd.org/@@196561?ac=10 Change 196561 by rene@rene_acer on 2011/07/22 20:06:38 network-servers: - sanity/spell fixes - update to future 1.135, which fixes file names from an example usage of dnssec-keygen. [1] Discussed with: gjb@ on bsddocs [1] Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#45 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#45 (text+ko) ==== @@ -4,7 +4,7 @@ $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml,v 1.32 2011/05/28 09:38:36 rene Exp $ %SOURCE% en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml - %SRCID% 1.134 + %SRCID% 1.135 --> @@ -4201,8 +4201,8 @@ DNS-records. Door digitale handtekeningen te gebruiken kan een resolver de integriteit van een record controleren. Merk op dat DNSSEC - alleen integriteit biedt via het digitaal ondertekenen van de Resource - Record (RRs). Het biedt noch + alleen integriteit biedt via het digitaal ondertekenen van het Resource + Record (RRs). Het biedt noch betrouwbaarheid noch bescherming tegen onjuiste aannames van eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen het bezoeken van voorbeeld.net in @@ -4223,7 +4223,7 @@ nodig om gebruik te kunnen maken van de ondertekende rootzones tijdens het valideren van DNS-verzoeken. Dit komt doordat eerdere versies de benodigde algoritmes om validatie met de sleutel - voor de rootzone te uit te veoren niet hebben. Het wordt sterk + voor de rootzone te uit te voeren niet hebben. Het wordt sterk aangeraden om de nieuwste versie van BIND 9.7 te gebruiken om gebruik te kunnen maken van automatische sleutel-updates voor de rootsleutel en van andere mogelijkheden om zones ondertekend en @@ -4311,7 +4311,7 @@ werken indien nodig. Dit wordt gedaan met managed-keys zoals in het volgende voorbeeld te zien is. Als de oudere versie gebruikt wordt, wordt de sleutel - toevoegd met een commando trusted-keys en dient + toegevoegd met een commando trusted-keys en dient deze handmatig bijgewerkt te worden. Voor BIND 9.6.2 ziet het formaat er uit als: @@ -4339,10 +4339,10 @@ QxA+Uk1ihz0="; }; - De root-sleutel kan nu aan named.conf worden + De rootsleutel kan nu aan named.conf worden toegevoegd, ofwel direct of door een bestand dat de sleutel bevat te includen. Stel na deze stappen BIND in zodat het - DNSSEC-validatie uitvoert op queries door + DNSSEC-validatie uitvoert op verzoeken door named.conf te bewerken en het volgende aan de directief options toe te voegen: @@ -4350,11 +4350,11 @@ dnssec-validation yes; Om te controleren dat het ook echt werkt, kan - dig gebruikt worden om een query op een + dig gebruikt worden om een verzoek op een ondertekende zone uit te voeren met de zojuist geconfigureerde resolver. Een succesvol antwoord zal de vlag AD bevatten om aan te geven dat de gegevens zijn geautenticeerd. Een - query als + verzoek als &prompt.user; dig @resolver +dnssec se ds @@ -4367,7 +4367,7 @@ ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ... - De resolver is nu in staat om DNS-queries te + De resolver is nu in staat om DNS-verzoeken te autenticeren. @@ -4395,9 +4395,9 @@ operator. De KSK wordt gebruikt om een autoriteitsketen voor de te valideren gegevens op te bouwen en wordt daarom ook een Secure Entry Point (SEP)-sleutel genoemd. Een - message digest van deze sleutel, dat Delegation Signer (DS)-record genoemd wordt, moet + role="Secure Entry Point">SEP)-sleutel genoemd. Een + bericht-digest van deze sleutel, dat Delegation Signer (DS)-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 ZSK wordt @@ -4431,8 +4431,8 @@ 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 + &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 @@ -4440,19 +4440,18 @@ 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 + Onderteken tenslotte 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: + uit moeten zien: - &prompt.user; dnssec-signzone -o voorbeeld.com -k Kvoorbeeld.com+005+nnnnn.KSK voorbeeld.com.db Kvoorbeeld.com+005+nnnnn.ZSK.key + &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 @@ -4483,11 +4482,13 @@ 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 + kunnen de DNS-gegevens tijdelijk onbeschikbaar zijn + totdat de nieuwe sleutel door de DNS-hiërarchie + is gepropageerd. Meer informatie over sleutelwisselingen en andere praktijken rondom DNSSEC staan in RFC - 4641: DNSSEC Operational practices. + 4641: DNSSEC Operational + practices. @@ -4562,7 +4563,7 @@ Verder lezen BIND/named hulppagina's: - &man.rndc.8;, &man.named.8;, &man.named.conf.5; &man.nsupdate.8; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; &man.dnssec-signzone.8; &man.dnssec-keygen.8; @@ -4598,38 +4599,38 @@ RFC1034 - - Domeinnamen - Concepten en Faciliteiten + Domain Names - Concepts and Facilitities RFC1035 - - Domeinnamen - Implementatie en Specificatie + Domain Names - Implementation and Specification RFC4033 - - DNS Beveiligingsintroductie en Benodigdheden + DNS Security Introduction and Requirements RFC4034 - - Resource Records voorde DNS-beveiligingsuitbreidingen + Resource Records for the DNS Security Extensions RFC4035 - - Protocolwijzigingen voor de DNS-beveiligingsuitbreidingen + Protocol Modifications for the DNS Security Extensions RFC4641 - - Operationeel gebruik van DNSSEC + DNSSEC Operational Practices RFC5011 - - Geautomatiseerde updates van DNS-beveiliging ( - DNSSEC Trust Anchors) + Automated Updates of DNS Security (DNSSEC Trust + Anchors)