From owner-p4-projects@FreeBSD.ORG Mon Jul 18 21:16:45 2011 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 5C79E1065670; Mon, 18 Jul 2011 21:16:45 +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 1ED88106564A for ; Mon, 18 Jul 2011 21:16:45 +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 0C5D18FC15 for ; Mon, 18 Jul 2011 21:16:45 +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 p6ILGihY000244 for ; Mon, 18 Jul 2011 21:16:44 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id p6ILGiqi000241 for perforce@freebsd.org; Mon, 18 Jul 2011 21:16:44 GMT (envelope-from rene@FreeBSD.org) Date: Mon, 18 Jul 2011 21:16:44 GMT Message-Id: <201107182116.p6ILGiqi000241@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 196369 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: Mon, 18 Jul 2011 21:16:45 -0000 http://p4web.freebsd.org/@@196369?ac=10 Change 196369 by rene@rene_acer on 2011/07/18 21:15:39 Some more of network-servers translated. Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#43 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#43 (text+ko) ==== @@ -4279,14 +4279,131 @@ role="Zone Signing Key">ZSK). Meer over de verschillende soorten sleutels komt aan bod in . - + + Nu moet de sleutel gecontroleerd en geformatteerd worden zodat + BIND deze kan gebruiken. Maak om de sleutel te + controleren een DS - + RR-paar aan. Maak een + bestand aan dat deze RRs + bevat aan met + + &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds + + 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. + + . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + + Het SHA-256 RR kan nu worden vergeleken met de + digest in https://data.iana.org/root-anchors/root-anchors.xml. + Om er absoluut zeker van te zijn dat er niet geknoeid is met de + sleutel kunnen de gegevens in het XML-bestand + worden gecontroleerd met de PGP-handtekening in + https//data.iana.org/root-anchors/root-anchors.asc. + + Vervolgens dient de sleutel juist geformateerd te worden. Dit + verschilt een beetje tussen versie 9.6.2 en versie 9.7 en later van + BIND. 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 + 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 + deze handmatig bijgewerkt te worden. Voor BIND + 9.6.2 ziet het formaat er uit als: + + trusted-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + Voor versie 9.7 ziet het formaat er echter zo uit: + + managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + De root-sleutel 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 + named.conf te bewerken en het volgende aan de + directief options toe te voegen: + + dnssec-enable yes; +dnssec-validation yes; + + Om te controleren dat het ook echt werkt, kan + dig gebruikt worden om een query 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 + + &prompt.user; dig @resolver +dnssec se ds + + zou het DS RR paar voor de + .se-zone moeten teruggeven. In de sectie + flags: moet de vlag AD te zien + zijn, als in: + + ... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + + De resolver is nu in staat om DNS-queries te + autenticeren. - Configuratie van een autoratieve <acronym>DNS</acronym>-server - + + Om een autoratieve naamserver een met DNSSEC + 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 (KSK) die niet vaak wordt geroteerd + en een Zone Signing Key (ZSK) die vaker wordt geroteerd te + hebben. Informatie over aanbevolen procedures staat in RFC + 4641: DNSSEC Operational Practices. + Procedures betreffende de rootzone staan in DNSSEC + Practice Statement for the Root Zone KSK + operator en DNSSEC + Practice Statement for the Root Zone ZSK + 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 + 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 + gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd + te worden. +