From owner-p4-projects@FreeBSD.ORG Tue Jul 5 21:20:14 2011 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D30741065670; Tue, 5 Jul 2011 21:20:14 +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 9430B106564A for ; Tue, 5 Jul 2011 21:20:14 +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 832068FC1C for ; Tue, 5 Jul 2011 21:20:14 +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 p65LKEPv096471 for ; Tue, 5 Jul 2011 21:20:14 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id p65LKE2s096467 for perforce@freebsd.org; Tue, 5 Jul 2011 21:20:14 GMT (envelope-from rene@FreeBSD.org) Date: Tue, 5 Jul 2011 21:20:14 GMT Message-Id: <201107052120.p65LKE2s096467@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 195778 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, 05 Jul 2011 21:20:15 -0000 http://p4web.freebsd.org/@@195778?ac=10 Change 195778 by rene@rene_acer on 2011/07/05 21:20:14 Checkpoint for network-servers 1.130 -> 1.134 update Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#42 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#42 (text+ko) ==== @@ -4185,6 +4185,112 @@ + <acronym + role="Domain Name Security Extensions">DNSSEC</acronym> + + + BIND + + DNS veiligheidsuitbreidingen + + + Domain Name Security System Extentions, ofwel DNSSEC, is een + verzameling van specificaties om resolvende naamservers te beschermen + tegen valse DNS-gegevens, zoals vervalste + 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 + betrouwbaarheid noch bescherming tegen onjuiste aannames van + eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen + het bezoeken van voorbeeld.net in + plaats van voorbeeld.com. Het enige + wat DNSSEC doet is authenticeren dat de gegevens + niet tijdens het transport zijn gecompromitteerd. De beveiliging van + DNSSEC is een belangrijke stap in het beveiligen van + het internet in het algemeen. De relevante RFCs zijn + een goed beginpunt voor meer gedetailleerde gegevens over hoe + DNSSEC werkt. Raadpleeg de lijst in + . + + De volgende secties laten zien hoe DNSSEC voor een + autoratieve DNS-server en een recursieve (of caching) + DNS-server die BIND 9 draait kan + worden bewerkstelligd. Hoewel alle versies van BIND + 9 DNSSEC ondersteunen, is tenminste versie 9.6.2 + 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 + 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 + sleutel up-to-date te houden. Wanneer configuraties tussen 9.6.2 en 9.7 + en later verschillen, zullen deze worden toegelicht. + + + Configuratie van een recursieve + <acronym>DNS</acronym>-server + + Het aanzetten van DNSSEC-validatie van + verzoeken die door een recursieve DNS-server worden + uitgevoerd heeft enkele aanpassingen aan + named.conf 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 BIND begrijpt, dus moet + het handmatig in het juiste formaat omgezet worden. De sleutel zelf + kan verkregen worden door de rootzone ervoor met + dig te ondervragen. Door + + &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey + + te draaien, wordt de sleutel in root.dnskey + opgeslagen. De inhoud dient er ongeveer als volgt uit te zien: + + . 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 + + 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 ( + SEP) is, beter bekend als + een Key Signing Key (KSK). + De tweede sleutel, met de waarde 256, is een deelsleutel, beter bekend + als een Zone Signing Key (ZSK). Meer over de verschillende + soorten sleutels komt aan bod in . + + + + + + Configuratie van een autoratieve + <acronym>DNS</acronym>-server + + + + + Beveiliging Hoewel BIND de meest gebruikte implementatie van DNS is, is