From zeising@daemonic.se  Sun May 22 09:34:16 2011
Return-Path: <zeising@daemonic.se>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C721B1065674
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 09:34:16 +0000 (UTC)
	(envelope-from zeising@daemonic.se)
Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3])
	by mx1.freebsd.org (Postfix) with ESMTP id C823D8FC0A
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 09:34:14 +0000 (UTC)
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
	by mail.lysator.liu.se (Postfix) with ESMTP id 47E7540002
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 11:34:13 +0200 (CEST)
Received: by mail.lysator.liu.se (Postfix, from userid 1004)
	id 3994940006; Sun, 22 May 2011 11:34:13 +0200 (CEST)
Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.lysator.liu.se (Postfix) with ESMTPSA id C869940002
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 11:34:10 +0200 (CEST)
Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4])
	by mx.daemonic.se (Postfix) with ESMTPS id 53392119C04
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 11:34:10 +0200 (CEST)
Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10])
	by mail.daemonic.se (Postfix) with ESMTPS id 2011012B2DA
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 22 May 2011 11:34:10 +0200 (CEST)
Received: (from zeising@localhost)
	by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4M9Y9JL041108;
	Sun, 22 May 2011 11:34:09 +0200 (CEST)
	(envelope-from zeising)
Message-Id: <201105220934.p4M9Y9JL041108@vincent.daemonic.se>
Date: Sun, 22 May 2011 11:34:09 +0200 (CEST)
From: Niclas Zeising <niclas.zeising@gmail.com>
Reply-To: Niclas Zeising <niclas.zeising@gmail.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         157245
>Category:       docs
>Synopsis:       [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bcr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 22 09:40:08 UTC 2011
>Closed-Date:    Wed May 25 14:31:53 UTC 2011
>Last-Modified:  Wed May 25 14:31:53 UTC 2011
>Originator:     Niclas Zeising
>Release:        FreeBSD 8.2-RELEASE amd64
>Organization:
>Environment:
System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64


	
>Description:
	DNSSEC is deemd to be very important in order to secure the Internet as a whole  I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook.
	As a first step, I would like some review on my work, both from a technical and a linguistic point of view.
>How-To-Repeat:
	
>Fix:

	Attached patch contains my changes to the handbook to include information about DNSSEC. Please review it as a first step, so that I can work on getting it into the handbook.

--- network-servers.chapter.sgml.diff begins here ---
Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
retrieving revision 1.130
diff -u -d -r1.130 chapter.sgml
--- chapter.sgml	15 May 2011 20:41:30 -0000	1.130
+++ chapter.sgml	21 May 2011 19:13:24 -0000
@@ -3872,6 +3872,293 @@
     </sect2>
 
     <sect2>
+      <title>DNSSEC</title>
+      <indexterm>
+        <primary>BIND</primary>
+        <secondary>DNS security extensions</secondary>
+      </indexterm>
+
+      <para>Domain Name System Security Extensions, or <acronym>DNSSEC</acronym>
+	for short, is a suite of specifications to protect the 
+	<acronym>DNS</acronym> clients, i.e. Internet resolvers, from forged
+	<acronym>DNS</acronym> data, such as spoofed <acronym>DNS</acronym>
+	records.  By using digital signatures, a resolver can verify the
+	integrity and authenticity of the record.  It is worth noticing that
+	<acronym>DNSSEC</acronym> does only provide integrity, it does not
+	provide either confidentiality nor protection against false assumptions,
+	meaning that it cannot protect against people going to 
+	<hostid role="domainname">example.com</hostid> instead of 
+	<hostid role="domainname">example.net</hostid> and similar.  The only 
+	thing <acronym>DNSSEC</acronym> does is authenticate that the data is 
+	from the domain owner and that it has not been compromised in transit. 
+	The security of <acronym>DNS</acronym> is believed to be an important 
+	step in securing the Internet in general.  For a more in-depth 
+	knowledge of how <acronym>DNSSEC</acronym> works, the relevant
+	<acronym>RFC</acronym>s is a good place to start.  See the list at the
+	end of this chapter.</para>
+
+      <para>The next two sections will demonstrate how to enable
+	<acronym>DNSSEC</acronym> for an authorative <acronym>DNS</acronym>
+	server and a recursive (or cashing) <acronym>DNS</acronym> server
+	running <acronym>BIND</acronym>9.  While all versions of
+	<acronym>BIND</acronym>9 supports <acronym>DNSSEC</acronym>, it is
+	necessary to have at least version 9.6.2 in order to be able to use the
+	signed root zone when validating <acronym>DNS</acronym> queries.  This is
+	because earlier versions lack the required algorithms to enable
+	validation using the root zone key.  It is strongly recommended to use
+	<acronym>BIND</acronym> 9.7 or later, to take advantage of the automatic
+	key updating function for the root key, as well as other functions to
+	automatically keep zones signed and signatures up to date.  Where
+	configurations differ between 9.6.2 and 9.7 and later, differences will
+	be pointed out.</para>
+
+      <sect3>
+	<title>Recursive <acronym>DNS</acronym> server configuration</title>
+
+	<para>To enable <acronym>DNSSEC</acronym> validation of queries done by
+	  a recursive <acronym>DNS</acronym> server, a few changes to
+	  <filename>named.conf</filename> are needed.  However, before changing
+	  <filename>named.conf</filename> the root zone key, or trust anchor,
+	  must be aquired.  Currently the root zone key is not available in a
+	  file format <acronym>BIND</acronym> understands, so this has to be
+	  manually generated.  The key itself can be obtained by querying the
+	  root zone for it, using <appication>dig</application>.  By running 
+	  <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY .
+	  &gt; root.dnskey</userinput></screen> the key will end up in
+	  <filename>root.dnskey</filename>. The contents should look something
+	  like this:<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>Do not be alarmed if the keys differ, they might
+          have changed since this was last updated.  This output actually
+          contains two keys.  The first key in the listing, with the value 257
+          behind the DNSKEY record type, is the one needed. The value
+          indicates that this is a Secure Entry Point, more commonly known as
+          a Key Signing Key (<acronym role="Key Signing Key">KSK</acronym>).
+          The second key, with value 256, is a subordinate key, commonly 
+          called a Zone Signing Key
+          (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
+          different key types later in the section <xref
+          linkend="dns-dnssec-auth">.</para>
+
+        <para>Now that the key is obtained, it has to be verified to be
+          correct, and then made into a format <acronym>BIND</acronym> can
+          use.  The next step is to generate a
+          <acronym role="Delegation signer">DS</acronym> 
+          <acronym role="Resource Record">RR</acronym> set.  This is done by
+          running <screen>&propmt.user; <userinput>dnssec-dsfromkey -f
+          root-dnskey . &gt; root.ds</userinput></screen>, which will emit two
+          <acronym>RR</acronyms>s into <filename>root.ds</filename>.  These
+          records are using SHA-1 and SHA-256 respectively, and should look
+          similar to this, where the longer is using SHA-256.<programlisting>
+. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
+. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
+	  </programlisting>The SHA-256 <acronym>RR</acronym> can now be
+	  compared to the digest in <ulink
+	  url="https://data.iana.org/root-anchors/root-anchors.xml">
+	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
+	  absolutely sure that the key has not been tampered with, the data in
+	  the <acronym>XML</acronym> file can be verified using the
+	  <acronym>PGP</acronym> signature in <ulink
+	  url="https://data.iana.org/root-anchors/root-anchors.asc">
+	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
+	    
+	<para>The last step is to format the key to a format
+	  <acronym>BIND</acronym> understand. This differs a little between
+	  version 9.6.2 and 9.7 and later.  Both uses a
+	  <literal>managed-keys</literal> clause, but support for
+	  <literal>initial-key</literal> was added in 9.7.
+	  <literal>initial-key</literal> tells <acronym>BIND</acronym>
+	  automatic tracking of the key. With <acronym>BIND</acronym> 9.6.2
+	  it is necessary to update the key manually when it is changed. The
+	  format should look like, for <acronym>BIND</acronym> 9.6.2:
+	  <programlisting>
+managed-keys {
+	"." 257 3 8
+	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+	QxA+Uk1ihz0=";
+};
+	  </programlisting>For 9.7 the format will instead be:
+	  <programlisting>
+managed-keys {
+        "." initial-key 257 3 8
+	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
+	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
+	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
+	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
+	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
+	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
+	QxA+Uk1ihz0=";
+};
+	  </programlisting>The <literal>managed-keys</literal> directive can
+	  now be added to <filename>named.conf</filename> either directly or
+	  by including a file containing the key.  After all this is done it
+	  is just to tell <acronym>BIND</acronym> to do
+	  <acronym>DNSSEC</acronym> validation on queries.  This is achieved by
+	  editing <filename>named.conf</filename> and add the following to the
+	  <literal>options</literal> directive:<programlisting>
+dnssec-enable yes;
+dnssec-validation yes;
+            </programlisting></para>
+
+	<para>To verify that it is actually working, use
+	  <application>dig</application> to make a query for a signed zone
+	  using the resolver just set up.  A successful reply will contain
+	  the <literal><acronym role="Authenticated Data">AD</acronym>
+	  </literal> flag to indicate the data was authenticated.  Running a
+	  query such as <screen>&prompt.user; <userinput>dig @resolver +dnssec
+	  se ds</userinput><screen> should return the <acronym>DS</acronym>
+	  <acronym>RR</acronyms> for the .se zone.  In the
+	  <literal>flags:</literal> section the
+	  <literal><acronym>AD</acronym></literal> flag should be set, as seen
+	  in:<programlisting>
+...
+;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
+...
+	  </programlisting>.  This means that the resolver is now capable of
+	  authenticate made <acronym>DNS</acronym>queries.</para>
+      </sect3>
+
+      <sect3 id="dns-dnssec-auth">
+        <title>Authorative <acronym>DNS</acronym> server configuration</title>
+        <para>In order to get an authorative nameserver to serve a
+          <acronym>DNSSEC</acronym> signed zone, a little more work is
+          required.  To sign a zone, two cryptographic keys for that zone must
+          be generated. These two keys are usually called the Key Signing Key
+          (<acronym role="Key Signing Key">KSK</acronym>) and Zone Signing Key
+          (<acronym role="Zone Signing Key">ZSK</acronym>) respectively.  The
+          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
+          of authority to the data in need of validation and as such also called
+          a Secure Entry Point (<acronym role="Secure Entry
+          Point">SEP</acronym>) key.  This key needs to be published in the
+          parent zone as well, to establish the trust chain.  How this is
+          accomplished depends on the parent zone owner. The <acronym role="Zone
+          Signing Key">ZSK</acronym> is used to sign the zone, and only needs to
+          be published there.</para>
+
+        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
+          role="domainname">example.com</hostid> zone depicted in previous
+          examples, the first step is to use
+          <application>dnssec-keygen</application> to generate the
+          <acronym>KSK</acronym> and <acronym>ZSK</acronym> keypair.  This keypair
+          can utilize different cryptograhic algorithms.  Currently the mandatory
+          algorithm is <literal>RSA/SHA-1</literal>.  In the examples the key
+          length used is 2048 bits for the <acronym>KSK</acronym> and 1024 bits
+          for the <acronym>ZSK</acronym>.  To generate the
+          <acronym>KSK</acronym> for <hostid
+          role="domainname">example.com</hostid>, run <screen>&promt.user;
+          <userinput>dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE
+          example.com</userinput></screen> and to generate the
+          <acronym>ZSK</acronym>, run <screen>&promt.user;
+          <userinput>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE
+          example.com</userinput></screen>.
+          <application>dnssec-keygen</application> outputs two files, the public
+          and the private keys in files named similar to
+          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
+          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
+          <literal>nnnnn</literal> part of the file name is a five digit key ID.
+          Keep track of which key ID belongs to which key.  This is especially
+          important when having more than one key in a zone.  The public key
+          files can now be included in the zone file, using the
+          <literal>$include</literal> statement. It should look something like
+          this:<programlisting>
+$include Kexample.net.+005+nnnnn.key    ; ZSK
+$include Kexample.net.+005+nnnnn.key    ; KSK
+	  </programlisting></para>
+
+	<para>The only steps left is to sign the zone and tell
+	  <acronym>BIND</acronym> to use the signed zonefile.  To sign a zone
+	  <application>dnssec-signzone</application> is used.  The command to
+	  sign the zone <hostid role="domainname">example.com</hostid>, located in
+	  <filename>example.com.db</filename> would look similar to
+	  <screen>&promt.user; <userinput>dnssec-signzone -o example.com -k
+	  Kexample.com+005+nnnnn example.com.db
+	  Kexample.com+005+nnnnn.key</userinput></screen>. The key supplied to
+	  the <literal>-k</literal> argument is the <acronym>KSK</acronym> and
+	  the other key file is the <acronym>ZSK</acronym> that should be used
+	  in the signing.  It is possible to supply more than one
+	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, which will result
+	  in the zone being signed with all supplied keys.  This can be needed
+	  to supply zone data signed using more than one algorithm.  The output
+	  of <application>dnssec-signzone</application> is a zone file with all
+	  <acronym>RR</acronym>s signed.  This output will end up in a file with
+	  the extension <literal>.signed</literal>, such as
+	  <filename>example.com.db.signed</filename>.  To use this signed zone
+	  just modify the zone directive in <filename>named.conf</filename> to
+	  use this file.  By default, the signatures are only valid 30 days,
+	  meaning that the zone needs to be resigned within this time.  It is
+	  possible to make a script and a cron job to do this.  See relevant
+	  manuals for details.</para>
+	<para>Some cautionary words at the end.  Be sure to keep private keys
+	  confidential, as with all cryptographic keys.  When changing a key it
+	  is best to include the new key into the zone, while still signing with
+	  the old key, and then move over to using the new key to sign.  After
+	  these steps are done the old key can be removed from the zone.
+	  Failiure to do this might render the <acronym>DNS</acronym> data
+	  unavailable for a time, untill the new key has propagated through the
+	  <acronym>DNS</acronym> hierarchy.  For more information on key
+	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
+	  <ulink
+	  url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> 4641:
+	  <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>
+      </sect3>
+
+      <sect3>
+        <title>Automation using <acronym>BIND</acronym>9.7 or later</title>
+        <para>Beginning with <acronym>BIND</acronym> version 9.7, a new feature
+          called <emphasis>Smart Signing</emphasis> was introduced.  This
+          feature aims to make the key management and signing process simpler by
+          automating parts of the task.  By putting the keys into a directory,
+          from now on called a key repository, and using the new option
+          <literal>auto-dnssec</literal> it is possible to create a dynamic zone
+          which will be resigned as needed.  To update this zone the tool
+          <application>nsupdate</application> with the new option
+          <literal>-l</literal> is used. <application>rndc</application> has
+          also grown the ability to sign zones with keys in the key repository,
+          using the option <literal>sign</literal>.  To make this work, put
+          something similar to what is shown below into
+          <filename>named.conf</filename>.<programlisting>
+zone example.com {
+	type master;
+	key-directory "keys";
+	update-policy local;
+	auto-dnssec maintain;
+	file "dynamic/example.com.zone";
+};
+	  </programlisting>This will tell named to use automatic signing and
+	  updating of the zone <hostid role="domainname">example.com</hostid>.
+	  After this is done just generate keys for the zone as explained in
+	  <xref linkened="dns-dnssec-auth">, put these in the key repository
+	  denoted by <literal>key-directory</literal> in the zone configuration
+	  and sign the zone using <application>rndc</application>.  Updates to
+	  the zone is done using <application>nsupdate</application> which will
+	  take care of resigning the zone with the new data added.  For further
+	  details, see <xref linkened="dns-read"> and the
+	  <acronym>BIND</acronym> documentation.</para>
+	</sect3>
+
+    </sect2>
+
+    <sect2>
       <title>Security</title>
 
       <para>Although BIND is the most common implementation of DNS,
@@ -3897,7 +4184,7 @@
       </tip>
     </sect2>
 
-    <sect2>
+    <sect2 id="dns-read">
       <title>Further Reading</title>
 
       <para>BIND/<application>named</application> manual pages:
@@ -3932,6 +4219,38 @@
 	      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
+	      - Recource 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">RFC 5011
+	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
+	      Trust Anchors</ulink></para>
+	</listitem>
+
       </itemizedlist>
     </sect2>
   </sect1>
--- network-servers.chapter.sgml.diff ends here ---


>Release-Note:
>Audit-Trail:

From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Niclas Zeising <niclas.zeising@gmail.com>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-doc@freebsd.org
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS	chapter in the handbook
Date: Sun, 22 May 2011 14:26:50 -0400 (EDT)

 On Sun, 22 May 2011, Niclas Zeising wrote:
 
 >
 >
 >> Description:
 > 	DNSSEC is deemd to be very important in order to secure the Internet as a whole  I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook.
 > 	As a first step, I would like some review on my work, both from a technical and a linguistic point of view.
 
 I can't do a technical review, but found a few language nits.
 
 >
 > --- network-servers.chapter.sgml.diff begins here ---
 > Index: chapter.sgml
 > ===================================================================
 > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 > retrieving revision 1.130
 > diff -u -d -r1.130 chapter.sgml
 > --- chapter.sgml	15 May 2011 20:41:30 -0000	1.130
 > +++ chapter.sgml	21 May 2011 19:13:24 -0000
 > @@ -3872,6 +3872,293 @@
 >     </sect2>
 >
 >     <sect2>
 > +      <title>DNSSEC</title>
 > +      <indexterm>
 > +        <primary>BIND</primary>
 > +        <secondary>DNS security extensions</secondary>
 > +      </indexterm>
 > +
 > +      <para>Domain Name System Security Extensions, or <acronym>DNSSEC</acronym>
 > +	for short, is a suite of specifications to protect the
 
 s/ the$//
 
 > +	<acronym>DNS</acronym> clients, i.e. Internet resolvers, from forged
 > +	<acronym>DNS</acronym> data, such as spoofed <acronym>DNS</acronym>
 > +	records.  By using digital signatures, a resolver can verify the
 > +	integrity and authenticity of the record.  It is worth noticing that
 > +	<acronym>DNSSEC</acronym> does only provide integrity, it does not
 
 This phrasing is a rather uncommon usage; "DNSSEC only provides integrity" 
 is what would more commonly be seen.
 
 > +	provide either confidentiality nor protection against false assumptions,
 
 I believe that "nor" should be "or" here, but I don't have a good 
 reference with me at the moment to check.
 
 > +	meaning that it cannot protect against people going to
 > +	<hostid role="domainname">example.com</hostid> instead of
 > +	<hostid role="domainname">example.net</hostid> and similar.  The only
 > +	thing <acronym>DNSSEC</acronym> does is authenticate that the data is
 > +	from the domain owner and that it has not been compromised in transit.
 > +	The security of <acronym>DNS</acronym> is believed to be an important
 > +	step in securing the Internet in general.  For a more in-depth
 > +	knowledge of how <acronym>DNSSEC</acronym> works, the relevant
 > +	<acronym>RFC</acronym>s is a good place to start.  See the list at the
 
 s/is/are/
 
 > +	end of this chapter.</para>
 > +
 > +      <para>The next two sections will demonstrate how to enable
 > +	<acronym>DNSSEC</acronym> for an authorative <acronym>DNS</acronym>
 
 "authoritative"
 
 > +	server and a recursive (or cashing) <acronym>DNS</acronym> server
 
 "caching"
 
 > +	running <acronym>BIND</acronym>9.  While all versions of
 > +	<acronym>BIND</acronym>9 supports <acronym>DNSSEC</acronym>, it is
 
 s/supports/support/
 
 > +	necessary to have at least version 9.6.2 in order to be able to use the
 > +	signed root zone when validating <acronym>DNS</acronym> queries.  This is
 > +	because earlier versions lack the required algorithms to enable
 > +	validation using the root zone key.  It is strongly recommended to use
 > +	<acronym>BIND</acronym> 9.7 or later, to take advantage of the automatic
 > +	key updating function for the root key, as well as other functions to
 > +	automatically keep zones signed and signatures up to date.  Where
 > +	configurations differ between 9.6.2 and 9.7 and later, differences will
 > +	be pointed out.</para>
 > +
 > +      <sect3>
 > +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 > +
 > +	<para>To enable <acronym>DNSSEC</acronym> validation of queries done by
 > +	  a recursive <acronym>DNS</acronym> server, a few changes to
 > +	  <filename>named.conf</filename> are needed.  However, before changing
 > +	  <filename>named.conf</filename> the root zone key, or trust anchor,
 > +	  must be aquired.  Currently the root zone key is not available in a
 > +	  file format <acronym>BIND</acronym> understands, so this has to be
 > +	  manually generated.  The key itself can be obtained by querying the
 
 I guess the point is that IANA doesn't distribute the key in this form? 
 This sentence ("Currently...generated.") could probably be reworked to 
 make it more clear that we need to get the root zone key and then convert 
 it to a format that BIND understands.
 
 > +	  root zone for it, using <appication>dig</application>.  By running
 > +	  <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY .
 > +	  &gt; root.dnskey</userinput></screen> the key will end up in
 > +	  <filename>root.dnskey</filename>. The contents should look something
 > +	  like this:<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>Do not be alarmed if the keys differ, they might
 
 "the keys" is ambiguous.  What we care about is the keys the reader gets 
 as compared to the ones listed here, since the root key currently in use 
 might have changed since our document was last updated.
 
 > +          have changed since this was last updated.  This output actually
 > +          contains two keys.  The first key in the listing, with the value 257
 > +          behind the DNSKEY record type, is the one needed. The value
 > +          indicates that this is a Secure Entry Point, more commonly known as
 > +          a Key Signing Key (<acronym role="Key Signing Key">KSK</acronym>).
 > +          The second key, with value 256, is a subordinate key, commonly
 > +          called a Zone Signing Key
 > +          (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 > +          different key types later in the section <xref
 > +          linkend="dns-dnssec-auth">.</para>
 > +
 > +        <para>Now that the key is obtained, it has to be verified to be
 > +          correct, and then made into a format <acronym>BIND</acronym> can
 > +          use.  The next step is to generate a
 > +          <acronym role="Delegation signer">DS</acronym>
 > +          <acronym role="Resource Record">RR</acronym> set.  This is done by
 > +          running <screen>&propmt.user; <userinput>dnssec-dsfromkey -f
 > +          root-dnskey . &gt; root.ds</userinput></screen>, which will emit two
 > +          <acronym>RR</acronyms>s into <filename>root.ds</filename>.  These
 > +          records are using SHA-1 and SHA-256 respectively, and should look
 > +          similar to this, where the longer is using SHA-256.<programlisting>
 > +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 > +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
 > +	  </programlisting>The SHA-256 <acronym>RR</acronym> can now be
 > +	  compared to the digest in <ulink
 > +	  url="https://data.iana.org/root-anchors/root-anchors.xml">
 > +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 > +	  absolutely sure that the key has not been tampered with, the data in
 > +	  the <acronym>XML</acronym> file can be verified using the
 > +	  <acronym>PGP</acronym> signature in <ulink
 > +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 > +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 > +
 > +	<para>The last step is to format the key to a format
 > +	  <acronym>BIND</acronym> understand. This differs a little between
 
 "understands"
 
 > +	  version 9.6.2 and 9.7 and later.  Both uses a
 
 "versions 9.6.2 and 9.7+", perhaps?  Certainly "versions" should be 
 plural.
 Also, s/uses/use/
 
 > +	  <literal>managed-keys</literal> clause, but support for
 > +	  <literal>initial-key</literal> was added in 9.7.
 > +	  <literal>initial-key</literal> tells <acronym>BIND</acronym>
 > +	  automatic tracking of the key. With <acronym>BIND</acronym> 9.6.2
 
 "initial-key tells BIND automatic tracking of the key" is not a complete 
 sentence.  If I had to guess, I'd say that the initial-key directive tells 
 BIND to automatically track the key, but I'm not entirely sure that's the 
 correct meaning.
 
 > +	  it is necessary to update the key manually when it is changed. The
 > +	  format should look like, for <acronym>BIND</acronym> 9.6.2:
 > +	  <programlisting>
 > +managed-keys {
 > +	"." 257 3 8
 > +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 > +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 > +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 > +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 > +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 > +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 > +	QxA+Uk1ihz0=";
 > +};
 > +	  </programlisting>For 9.7 the format will instead be:
 > +	  <programlisting>
 > +managed-keys {
 > +        "." initial-key 257 3 8
 > +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 > +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 > +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 > +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 > +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 > +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 > +	QxA+Uk1ihz0=";
 > +};
 > +	  </programlisting>The <literal>managed-keys</literal> directive can
 > +	  now be added to <filename>named.conf</filename> either directly or
 
 s/now//, I think.
 
 > +	  by including a file containing the key.  After all this is done it
 > +	  is just to tell <acronym>BIND</acronym> to do
 
 s/is just/only remains/
 
 > +	  <acronym>DNSSEC</acronym> validation on queries.  This is achieved by
 > +	  editing <filename>named.conf</filename> and add the following to the
 
 "adding", for consistency with "editing"
 
 > +	  <literal>options</literal> directive:<programlisting>
 > +dnssec-enable yes;
 > +dnssec-validation yes;
 > +            </programlisting></para>
 > +
 > +	<para>To verify that it is actually working, use
 > +	  <application>dig</application> to make a query for a signed zone
 > +	  using the resolver just set up.  A successful reply will contain
 
 s/just set up/as just configured/ would be less informal.
 
 > +	  the <literal><acronym role="Authenticated Data">AD</acronym>
 > +	  </literal> flag to indicate the data was authenticated.  Running a
 > +	  query such as <screen>&prompt.user; <userinput>dig @resolver +dnssec
 
 Is this "@resolver" supposed to be "@[IP address or hostname of resolver 
 just configured]"?  I suspect there is markup for this, if so.
 
 > +	  se ds</userinput><screen> should return the <acronym>DS</acronym>
 > +	  <acronym>RR</acronyms> for the .se zone.  In the
 > +	  <literal>flags:</literal> section the
 > +	  <literal><acronym>AD</acronym></literal> flag should be set, as seen
 > +	  in:<programlisting>
 > +...
 > +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 > +...
 > +	  </programlisting>.  This means that the resolver is now capable of
 > +	  authenticate made <acronym>DNS</acronym>queries.</para>
 
 The clause "now capable of authenticate made" doesn't make any sense to 
 me.
 
 > +      </sect3>
 > +
 > +      <sect3 id="dns-dnssec-auth">
 > +        <title>Authorative <acronym>DNS</acronym> server configuration</title>
 
 "Authoritative", again.
 
 > +        <para>In order to get an authorative nameserver to serve a
 
 and here.
 
 > +          <acronym>DNSSEC</acronym> signed zone, a little more work is
 > +          required.  To sign a zone, two cryptographic keys for that zone must
 > +          be generated. These two keys are usually called the Key Signing Key
 > +          (<acronym role="Key Signing Key">KSK</acronym>) and Zone Signing Key
 > +          (<acronym role="Zone Signing Key">ZSK</acronym>) respectively.  The
 > +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 > +          of authority to the data in need of validation and as such also called
 
 put an "is" in "and as such also called"; there's a couple of places to 
 choose from.
 
 > +          a Secure Entry Point (<acronym role="Secure Entry
 > +          Point">SEP</acronym>) key.  This key needs to be published in the
 > +          parent zone as well, to establish the trust chain.  How this is
 > +          accomplished depends on the parent zone owner. The <acronym role="Zone
 > +          Signing Key">ZSK</acronym> is used to sign the zone, and only needs to
 > +          be published there.</para>
 > +
 > +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 > +          role="domainname">example.com</hostid> zone depicted in previous
 > +          examples, the first step is to use
 > +          <application>dnssec-keygen</application> to generate the
 > +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> keypair.  This keypair
 > +          can utilize different cryptograhic algorithms.  Currently the mandatory
 > +          algorithm is <literal>RSA/SHA-1</literal>.  In the examples the key
 > +          length used is 2048 bits for the <acronym>KSK</acronym> and 1024 bits
 > +          for the <acronym>ZSK</acronym>.  To generate the
 > +          <acronym>KSK</acronym> for <hostid
 > +          role="domainname">example.com</hostid>, run <screen>&promt.user;
 > +          <userinput>dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE
 > +          example.com</userinput></screen> and to generate the
 > +          <acronym>ZSK</acronym>, run <screen>&promt.user;
 > +          <userinput>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE
 > +          example.com</userinput></screen>.
 > +          <application>dnssec-keygen</application> outputs two files, the public
 > +          and the private keys in files named similar to
 > +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 > +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 > +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 > +          Keep track of which key ID belongs to which key.  This is especially
 > +          important when having more than one key in a zone.  The public key
 > +          files can now be included in the zone file, using the
 > +          <literal>$include</literal> statement. It should look something like
 > +          this:<programlisting>
 > +$include Kexample.net.+005+nnnnn.key    ; ZSK
 > +$include Kexample.net.+005+nnnnn.key    ; KSK
 > +	  </programlisting></para>
 > +
 > +	<para>The only steps left is to sign the zone and tell
 
 s/is/are/
 
 > +	  <acronym>BIND</acronym> to use the signed zonefile.  To sign a zone
 > +	  <application>dnssec-signzone</application> is used.  The command to
 > +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 > +	  <filename>example.com.db</filename> would look similar to
 > +	  <screen>&promt.user; <userinput>dnssec-signzone -o example.com -k
 > +	  Kexample.com+005+nnnnn example.com.db
 > +	  Kexample.com+005+nnnnn.key</userinput></screen>. The key supplied to
 > +	  the <literal>-k</literal> argument is the <acronym>KSK</acronym> and
 > +	  the other key file is the <acronym>ZSK</acronym> that should be used
 > +	  in the signing.  It is possible to supply more than one
 > +	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, which will result
 > +	  in the zone being signed with all supplied keys.  This can be needed
 > +	  to supply zone data signed using more than one algorithm.  The output
 > +	  of <application>dnssec-signzone</application> is a zone file with all
 > +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 > +	  the extension <literal>.signed</literal>, such as
 > +	  <filename>example.com.db.signed</filename>.  To use this signed zone
 > +	  just modify the zone directive in <filename>named.conf</filename> to
 > +	  use this file.  By default, the signatures are only valid 30 days,
 > +	  meaning that the zone needs to be resigned within this time.  It is
 > +	  possible to make a script and a cron job to do this.  See relevant
 > +	  manuals for details.</para>
 > +	<para>Some cautionary words at the end.  Be sure to keep private keys
 > +	  confidential, as with all cryptographic keys.  When changing a key it
 > +	  is best to include the new key into the zone, while still signing with
 > +	  the old key, and then move over to using the new key to sign.  After
 > +	  these steps are done the old key can be removed from the zone.
 > +	  Failiure to do this might render the <acronym>DNS</acronym> data
 > +	  unavailable for a time, untill the new key has propagated through the
 > +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 > +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 > +	  <ulink
 > +	  url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> 4641:
 > +	  <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>
 > +      </sect3>
 > +
 > +      <sect3>
 > +        <title>Automation using <acronym>BIND</acronym>9.7 or later</title>
 > +        <para>Beginning with <acronym>BIND</acronym> version 9.7, a new feature
 > +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 > +          feature aims to make the key management and signing process simpler by
 > +          automating parts of the task.  By putting the keys into a directory,
 > +          from now on called a key repository, and using the new option
 > +          <literal>auto-dnssec</literal> it is possible to create a dynamic zone
 > +          which will be resigned as needed.  To update this zone the tool
 > +          <application>nsupdate</application> with the new option
 > +          <literal>-l</literal> is used. <application>rndc</application> has
 > +          also grown the ability to sign zones with keys in the key repository,
 > +          using the option <literal>sign</literal>.  To make this work, put
 > +          something similar to what is shown below into
 > +          <filename>named.conf</filename>.<programlisting>
 > +zone example.com {
 > +	type master;
 > +	key-directory "keys";
 > +	update-policy local;
 > +	auto-dnssec maintain;
 > +	file "dynamic/example.com.zone";
 > +};
 > +	  </programlisting>This will tell named to use automatic signing and
 > +	  updating of the zone <hostid role="domainname">example.com</hostid>.
 > +	  After this is done just generate keys for the zone as explained in
 > +	  <xref linkened="dns-dnssec-auth">, put these in the key repository
 > +	  denoted by <literal>key-directory</literal> in the zone configuration
 
 "denoted by" could be ambiguous -- "given as the argument to the 
 key-directory directive" might be better.
 
 > +	  and sign the zone using <application>rndc</application>.  Updates to
 > +	  the zone is done using <application>nsupdate</application> which will
 
 I'm not sure what is intended, here.  Is it trying to say that further 
 updates to the zone must only be done using nsupdate, which will 
 automatically re-sign the zone?
 
 > +	  take care of resigning the zone with the new data added.  For further
 > +	  details, see <xref linkened="dns-read"> and the
 > +	  <acronym>BIND</acronym> documentation.</para>
 > +	</sect3>
 > +
 > +    </sect2>
 > +
 > +    <sect2>
 >       <title>Security</title>
 >
 >       <para>Although BIND is the most common implementation of DNS,
 > @@ -3897,7 +4184,7 @@
 >       </tip>
 >     </sect2>
 >
 > -    <sect2>
 > +    <sect2 id="dns-read">
 >       <title>Further Reading</title>
 >
 >       <para>BIND/<application>named</application> manual pages:
 > @@ -3932,6 +4219,38 @@
 > 	      url="http://tools.ietf.org/html/rfc1035">RFC1035
 > 	      - Domain Names - Implementation and Specification</ulink></para>
 > 	</listitem>
 
 Hmm, I kind of want all of these to be &mdash;es.
 
 Thanks for putting together this DNSSEC section -- it will be really great 
 to have it more widely deployed!
 
 -Ben Kaduk
 
 > +
 > +	<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
 > +	      - Recource 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">RFC 5011
 > +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 > +	      Trust Anchors</ulink></para>
 > +	</listitem>
 > +
 >       </itemizedlist>
 >     </sect2>
 >   </sect1>
 > --- network-servers.chapter.sgml.diff ends here ---
 >
 >
 >> Release-Note:
 >> Audit-Trail:
 >> Unformatted:
 > _______________________________________________
 > freebsd-doc@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-doc
 > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org"
 >

From: Chuck Swiger <cswiger@mac.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Cc: Niclas Zeising <niclas.zeising@gmail.com>, freebsd-doc@freebsd.org,
 FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS
 chapter in the handbook
Date: Sun, 22 May 2011 11:57:06 -0700

 On May 22, 2011, at 11:26 AM, Benjamin Kaduk wrote:
 >> +	provide either confidentiality nor protection against false assumptions,
 > 
 > I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check.
 
 Agreed.  One uses "either" and "or" together, or "neither" and "nor".
 
 Regards,
 -- 
 -Chuck
 

From: Niclas Zeising <zeising@daemonic.se>
To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com
Cc:  
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Sun, 22 May 2011 23:45:05 +0200

 This is a multi-part message in MIME format.
 --------------020301000301000000020306
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 Hi!
 Here is an updated patch with changes based on suggestions from Ben
 Kaduk and Warren Block. Thank you very much for your help!
 
 -- 
 Niclas
 
 --------------020301000301000000020306
 Content-Type: text/plain;
  name="network-servers.chapter.sgml.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="network-servers.chapter.sgml.diff"
 
 Index: chapter.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 retrieving revision 1.130
 diff -u -d -r1.130 chapter.sgml
 --- chapter.sgml	15 May 2011 20:41:30 -0000	1.130
 +++ chapter.sgml	22 May 2011 20:40:32 -0000
 @@ -3872,6 +3872,293 @@
      </sect2>
  
      <sect2>
 +      <title>DNSSEC</title>
 +      <indexterm>
 +        <primary>BIND</primary>
 +        <secondary>DNS security extensions</secondary>
 +      </indexterm>
 +
 +      <para>Domain Name System Security Extensions, or <acronym>DNSSEC</acronym>
 +	for short, is a suite of specifications to protect
 +	<acronym>DNS</acronym> clients, i.e. Internet resolvers, from forged
 +	<acronym>DNS</acronym> data, such as spoofed <acronym>DNS</acronym>
 +	records.  By using digital signatures, a resolver can verify the
 +	integrity and authenticity of the record.  Note that
 +	<acronym>DNSSEC</acronym> only provides integrity, it does not
 +	provide neither confidentiality nor protection against false
 +	assumptions.  This meanins that it cannot protect against people going
 +	to <hostid role="domainname">example.net</hostid> instead of
 +	<hostid role="domainname">example.com</hostid>.  The only 
 +	thing <acronym>DNSSEC</acronym> does is authenticate that the data is 
 +	from the domain owner and that it has not been compromised in transit. 
 +	The security of <acronym>DNS</acronym> is believed to be an important 
 +	step in securing the Internet in general.  For a more in-depth 
 +	details of how <acronym>DNSSEC</acronym> works, the relevant
 +	<acronym>RFC</acronym>s are a good place to start.  See the list in
 +	<xref linkened="dns-read">.
 +
 +      <para>The next two sections will demonstrate how to enable
 +	<acronym>DNSSEC</acronym> for an authoritative <acronym>DNS</acronym>
 +	server and a recursive (or caching) <acronym>DNS</acronym> server
 +	running <acronym>BIND</acronym>9.  While all versions of
 +	<acronym>BIND</acronym>9 support <acronym>DNSSEC</acronym>, it is
 +	necessary to have at least version 9.6.2 in order to be able to use the
 +	signed root zone when validating <acronym>DNS</acronym> queries.  This is
 +	because earlier versions lack the required algorithms to enable
 +	validation using the root zone key.  It is strongly recommended to use
 +	<acronym>BIND</acronym> 9.7 or later to take advantage of automatic
 +	key updating for the root key, as well as other features to 
 +	automatically keep zones signed and signatures up to date.  Where
 +	configurations differ between 9.6.2 and 9.7 and later, differences
 +	will be pointed out.</para>
 +
 +      <sect3>
 +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>Enabling <acronym>DNSSEC</acronym> validation of queries done by
 +	  a recursive <acronym>DNS</acronym> server reqires a few changes to
 +	  <filename>named.conf</filename>.  Before making these changes
 +	  the root zone key, or trust anchor, must be aquired.  Currently the
 +	  root zone key is not available in a file format
 +	  <acronym>BIND</acronym> understands, so it has to be manually
 +	  converted into the proper format.  The key itself can be obtained by
 +	  querying the root zone for it, using <application>dig</application>.
 +	  By running <screen>&prompt.user; <userinput>dig +multi +noall
 +	  +answer DNSKEY . &gt; root.dnskey</userinput></screen> the key will
 +	  end up in <filename>root.dnskey</filename>. The contents should look
 +	  something like this:<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>Do not be alarmed if the obtained keys differ from
 +          this example, they might have changed since these instructions were
 +          last updated.  This output actually contains two keys.  The first
 +          key in the listing, with the value 257 behind the DNSKEY record
 +          type, is the one needed. This value indicates that this is a 
 +          Secure Entry Point (<acronym role="Secure Entry Point">SEP</acronym>,
 +          more commonly known as a Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>). The second key,
 +          with value 256, is a subordinate key, commonly called a Zone Signing
 +          Key (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 +          different key types later in the section <xref
 +          linkend="dns-dnssec-auth">.</para>
 +
 +        <para>Now the key must be verified verified and formatted so that
 +          <acronym>BIND</acronym> can use it.  To verify the key, generate a
 +          <acronym role="Delegation signer">DS</acronym> 
 +          <acronym role="Resource Record">RR</acronym> set.  Create a file
 +          containing these <acronym role="Resource Record">RR</acronym>s with 
 +          <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey .
 +          &gt; root.ds</userinput></screen>.  These records use SHA-1 and
 +          SHA-256 respectively, and should look similar to the following
 +          example, where the longer is using SHA-256.<programlisting>
 +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
 +	  </programlisting>The SHA-256 <acronym>RR</acronym> can now be
 +	  compared to the digest in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.xml">
 +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 +	  absolutely sure that the key has not been tampered with, the data in
 +	  the <acronym>XML</acronym> file can be verified using the
 +	  <acronym>PGP</acronym> signature in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 +	    
 +	<para>Next, the key must be formatted properly.  This differs a
 +	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and
 +	  later.  Both use a <literal>managed-keys</literal> clause, but
 +	  support for <literal>initial-key</literal> was added in 9.7.
 +	  <literal>initial-key</literal> makes <acronym>BIND</acronym>
 +	  automatically track changes to the key and update it as necesarry.
 +	  Users of <acronym>BIND</acronym> 9.6.2 must do this manually.
 +	  For <acronym>BIND</acronym> 9.6.2 the format should look like:
 +	  <programlisting>
 +managed-keys {
 +	"." 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};
 +	  </programlisting>For 9.7 the format will instead be:
 +	  <programlisting>
 +managed-keys {
 +        "." initial-key 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};
 +	  </programlisting>The <literal>managed-keys</literal> directive can
 +	  now be added to <filename>named.conf</filename> either directly or
 +	  by including a file containing the key.  After these steps, tell
 +	  <acronym>BIND</acronym> to do <acronym>DNSSEC</acronym> validation
 +	  on queries by editing <filename>named.conf</filename> and adding the
 +	  following to the <literal>options</literal> directive:
 +	  <programlisting>
 +dnssec-enable yes;
 +dnssec-validation yes;
 +          </programlisting></para>
 +
 +	<para>To verify that it is actually working, use
 +	  <application>dig</application> to make a query for a signed zone
 +	  using the resolver just configured.  A successful reply will contain
 +	  the <literal><acronym role="Authenticated Data">AD</acronym>
 +	  </literal> flag to indicate the data was authenticated.  Running a
 +	  query such as <screen>&prompt.user; <userinput>dig
 +	  @<replaceable>resolver</replaceable> +dnssec se ds
 +	  </userinput><screen> should return the <acronym>DS</acronym>
 +	  <acronym>RR</acronyms> for the .se zone.  In the
 +	  <literal>flags:</literal> section the
 +	  <literal><acronym>AD</acronym></literal> flag should be set, as seen
 +	  in:<programlisting>
 +...
 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 +...
 +	  </programlisting>.  This means that the resolver is now capable of
 +	  authenticating <acronym>DNS</acronym>queries.</para>
 +      </sect3>
 +
 +      <sect3 id="dns-dnssec-auth">
 +        <title>Authoritative <acronym>DNS</acronym> server configuration</title>
 +        <para>In order to get an authoritative nameserver to serve a
 +          <acronym>DNSSEC</acronym> signed zone, a little more work is
 +          required.  To sign a zone, two cryptographic keys for that zone must
 +          be generated. These two keys are usually called the Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>) and Zone Signing Key
 +          (<acronym role="Zone Signing Key">ZSK</acronym>) respectively.  The
 +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 +          of authority to the data in need of validation and as such is also
 +          called a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>) key.  This key
 +          needs to be published in the parent zone as well, to establish the
 +          trust chain.  How this is accomplished depends on the parent zone
 +          owner. The <acronym role="Zone Signing Key">ZSK</acronym> is used
 +          to sign the zone, and only needs to be published there.</para>
 +
 +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 +          role="domainname">example.com</hostid> zone depicted in previous
 +          examples, the first step is to use
 +          <application>dnssec-keygen</application> to generate the
 +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> keypair.  This keypair
 +          can utilize different cryptograhic algorithms.  Currently the mandatory
 +          algorithm is <literal>RSA/SHA-1</literal>.  In the examples the key
 +          length used is 2048 bits for the <acronym>KSK</acronym> and 1024 bits
 +          for the <acronym>ZSK</acronym>.  To generate the
 +          <acronym>KSK</acronym> for <hostid
 +          role="domainname">example.com</hostid>, run <screen>&prompt.user;
 +          <userinput>dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE
 +          example.com</userinput></screen> and to generate the
 +          <acronym>ZSK</acronym>, run <screen>&prompt.user;
 +          <userinput>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE
 +          example.com</userinput></screen>.
 +          <application>dnssec-keygen</application> outputs two files, the public
 +          and the private keys in files named similar to
 +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 +          Keep track of which key ID belongs to which key.  This is especially
 +          important when having more than one key in a zone.  The public key
 +          files can now be included in the zone file, using the
 +          <literal>$include</literal> statement. It should look something like
 +          this:<programlisting>
 +$include Kexample.net.+005+nnnnn.key    ; ZSK
 +$include Kexample.net.+005+nnnnn.key    ; KSK
 +	  </programlisting></para>
 +
 +	<para>Finally, sign the zone and tell <acronym>BIND</acronym> to use
 +	  the signed zonefile.  To sign a zone
 +	  <application>dnssec-signzone</application> is used.  The command to
 +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 +	  <filename>example.com.db</filename> would look similar to
 +	  <screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k
 +	  Kexample.com+005+nnnnn example.com.db
 +	  Kexample.com+005+nnnnn.key</userinput></screen>. The key supplied to
 +	  the <literal>-k</literal> argument is the <acronym>KSK</acronym> and
 +	  the other key file is the <acronym>ZSK</acronym> that should be used
 +	  in the signing.  It is possible to supply more than one
 +	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, which will result
 +	  in the zone being signed with all supplied keys.  This can be needed
 +	  to supply zone data signed using more than one algorithm.  The output
 +	  of <application>dnssec-signzone</application> is a zone file with all
 +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 +	  the extension <literal>.signed</literal>, such as
 +	  <filename>example.com.db.signed</filename>.  To use this signed zone
 +	  just modify the zone directive in <filename>named.conf</filename> to
 +	  use this file.  By default, the signatures are only valid 30 days,
 +	  meaning that the zone needs to be resigned within this time.  It is
 +	  possible to make a script and a cron job to do this.  See relevant
 +	  manuals for details.</para>
 +	<para>Some cautionary words at the end.  Be sure to keep private keys
 +	  confidential, as with all cryptographic keys.  When changing a key it
 +	  is best to include the new key into the zone, while still signing with
 +	  the old key, and then move over to using the new key to sign.  After
 +	  these steps are done the old key can be removed from the zone.
 +	  Failiure to do this might render the <acronym>DNS</acronym> data
 +	  unavailable for a time, until the new key has propagated through the
 +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 +	  <ulink
 +	  url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> 4641:
 +	  <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>
 +      </sect3>
 +
 +      <sect3>
 +        <title>Automation using <acronym>BIND</acronym>9.7 or later</title>
 +        <para>Beginning with <acronym>BIND</acronym> version 9.7, a new feature
 +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 +          feature aims to make the key management and signing process simpler by
 +          automating parts of the task.  By putting the keys into a directory
 +          called a <emphasis>key repository</emphasis>, and using the new option
 +          <literal>auto-dnssec</literal>, it is possible to create a dynamic zone
 +          which will be resigned as needed.  To update this zone use
 +          <application>nsupdate</application> with the new option
 +          <option>-l</option>. <application>rndc</application> has
 +          also grown the ability to sign zones with keys in the key repository,
 +          using the option <option>sign</option>.  To tell
 +          <acronym>BIND</acronym> to use this automatic signing and zone
 +          updating for <hostid role="domainname">exanple.com<hostid>, add the
 +          following to <filename>named.conf</filename>:
 +zone example.com {
 +	type master;
 +	key-directory "keys";
 +	update-policy local;
 +	auto-dnssec maintain;
 +	file "dynamic/example.com.zone";
 +};
 +	  After making these changes, generate keys for the zone as explained in
 +	  <xref linkened="dns-dnssec-auth">, put those keys in the key repository
 +	  given as the argument to the <literal>key-directory</literal> in the
 +	  zone configuration and sign the zone using
 +	  <application>rndc</application>.  Updates to a zone configured this
 +	  way must be done using <application>nsupdate</application>, which will
 +	  take care of re-signing the zone with the new data added.  For further
 +	  details, see <xref linkened="dns-read"> and the
 +	  <acronym>BIND</acronym> documentation.</para>
 +	</sect3>
 +
 +    </sect2>
 +
 +    <sect2>
        <title>Security</title>
  
        <para>Although BIND is the most common implementation of DNS,
 @@ -3897,11 +4184,12 @@
        </tip>
      </sect2>
  
 -    <sect2>
 +    <sect2 id="dns-read">
        <title>Further Reading</title>
  
        <para>BIND/<application>named</application> manual pages:
 -      &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>
 @@ -3932,6 +4220,38 @@
  	      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
 +	      - Recource 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">RFC 5011
 +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 +	      Trust Anchors</ulink></para>
 +	</listitem>
 +
        </itemizedlist>
      </sect2>
    </sect1>
 
 --------------020301000301000000020306--

From: Niclas Zeising <niclas.zeising@gmail.com>
To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com
Cc:  
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Mon, 23 May 2011 01:25:55 +0200

 This is a multi-part message in MIME format.
 --------------040500050509000704050409
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 Here is a further updated patch. It fixes some typos and other similar
 stuff. It also adds manual pages to man-refs.ent.
 Regards!
 --
 Niclas
 
 --------------040500050509000704050409
 Content-Type: text/plain;
  name="network-servers.chapter.sgml.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="network-servers.chapter.sgml.diff"
 
 Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 retrieving revision 1.130
 diff -u -d -r1.130 chapter.sgml
 --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	15 May 2011 20:41:30 -0000	1.130
 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	22 May 2011 22:49:58 -0000
 @@ -3872,6 +3872,292 @@
      </sect2>
  
      <sect2>
 +      <title>DNSSEC</title>
 +      <indexterm>
 +        <primary>BIND</primary>
 +        <secondary>DNS security extensions</secondary>
 +      </indexterm>
 +
 +      <para>Domain Name System Security Extensions, or <acronym>DNSSEC</acronym>
 +	for short, is a suite of specifications to protect
 +	<acronym>DNS</acronym> clients, i.e. Internet resolvers, from forged
 +	<acronym>DNS</acronym> data, such as spoofed <acronym>DNS</acronym>
 +	records.  By using digital signatures, a resolver can verify the
 +	integrity and authenticity of the record.  Note that
 +	<acronym>DNSSEC</acronym> only provides integrity, it does not
 +	provide neither confidentiality nor protection against false
 +	assumptions.  This meanins that it cannot protect against people going
 +	to <hostid role="domainname">example.net</hostid> instead of
 +	<hostid role="domainname">example.com</hostid>.  The only 
 +	thing <acronym>DNSSEC</acronym> does is authenticate that the data is 
 +	from the domain owner and that it has not been compromised in transit. 
 +	The security of <acronym>DNS</acronym> is believed to be an important 
 +	step in securing the Internet in general.  For a more in-depth 
 +	details of how <acronym>DNSSEC</acronym> works, the relevant
 +	<acronym>RFC</acronym>s are a good place to start.  See the list in
 +	<xref linkend="dns-read">.
 +
 +      <para>The next two sections will demonstrate how to enable
 +	<acronym>DNSSEC</acronym> for an authoritative <acronym>DNS</acronym>
 +	server and a recursive (or caching) <acronym>DNS</acronym> server
 +	running <acronym>BIND</acronym>9.  While all versions of
 +	<acronym>BIND</acronym>9 support <acronym>DNSSEC</acronym>, it is
 +	necessary to have at least version 9.6.2 in order to be able to use the
 +	signed root zone when validating <acronym>DNS</acronym> queries.  This is
 +	because earlier versions lack the required algorithms to enable
 +	validation using the root zone key.  It is strongly recommended to use
 +	<acronym>BIND</acronym> 9.7 or later to take advantage of automatic
 +	key updating for the root key, as well as other features to 
 +	automatically keep zones signed and signatures up to date.  Where
 +	configurations differ between 9.6.2 and 9.7 and later, differences
 +	will be pointed out.</para>
 +
 +      <sect3>
 +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>Enabling <acronym>DNSSEC</acronym> validation of queries done by
 +	  a recursive <acronym>DNS</acronym> server reqires a few changes to
 +	  <filename>named.conf</filename>.  Before making these changes
 +	  the root zone key, or trust anchor, must be aquired.  Currently the
 +	  root zone key is not available in a file format
 +	  <acronym>BIND</acronym> understands, so it has to be manually
 +	  converted into the proper format.  The key itself can be obtained by
 +	  querying the root zone for it, using <application>dig</application>.
 +	  By running
 +	  <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . &gt; root.dnskey</userinput></screen>
 +	  the key will end up in <filename>root.dnskey</filename>. The
 +	  contents should look something like this:<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>Do not be alarmed if the obtained keys differ from
 +          this example, they might have changed since these instructions were
 +          last updated.  This output actually contains two keys.  The first
 +          key in the listing, with the value 257 behind the DNSKEY record
 +          type, is the one needed. This value indicates that this is a 
 +          Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>),
 +          more commonly known as a Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>). The second key,
 +          with value 256, is a subordinate key, commonly called a Zone Signing
 +          Key (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 +          different key types later in the <xref linkend="dns-dnssec-auth">.
 +        </para>
 +
 +        <para>Now the key must be verified verified and formatted so that
 +          <acronym>BIND</acronym> can use it.  To verify the key, generate a
 +          <acronym role="Delegation signer">DS</acronym> 
 +          <acronym role="Resource Record">RR</acronym> set.  Create a file
 +          containing these <acronym role="Resource Record">RR</acronym>s with 
 +          <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . &gt; root.ds</userinput></screen>
 +          These records use SHA-1 and SHA-256 respectively, and should look
 +          similar to the following example, where the longer is using SHA-256.
 +          <programlisting>
 +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
 +	  </programlisting>The SHA-256 <acronym>RR</acronym> can now be
 +	  compared to the digest in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.xml">
 +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 +	  absolutely sure that the key has not been tampered with, the data in
 +	  the <acronym>XML</acronym> file can be verified using the
 +	  <acronym>PGP</acronym> signature in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 +	    
 +	<para>Next, the key must be formatted properly.  This differs a
 +	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and
 +	  later.  Both use a <literal>managed-keys</literal> clause, but
 +	  support for <literal>initial-key</literal> was added in 9.7.
 +	  <literal>initial-key</literal> makes <acronym>BIND</acronym>
 +	  automatically track changes to the key and update it as necesarry.
 +	  Users of <acronym>BIND</acronym> 9.6.2 must do this manually.
 +	  For <acronym>BIND</acronym> 9.6.2 the format should look like:
 +	  <programlisting>
 +managed-keys {
 +	"." 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};
 +	  </programlisting>For 9.7 the format will instead be:
 +	  <programlisting>
 +managed-keys {
 +        "." initial-key 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};
 +	  </programlisting>The <literal>managed-keys</literal> directive can
 +	  now be added to <filename>named.conf</filename> either directly or
 +	  by including a file containing the key.  After these steps, tell
 +	  <acronym>BIND</acronym> to do <acronym>DNSSEC</acronym> validation
 +	  on queries by editing <filename>named.conf</filename> and adding the
 +	  following to the <literal>options</literal> directive:
 +	  <programlisting>
 +dnssec-enable yes;
 +dnssec-validation yes;
 +          </programlisting></para>
 +
 +	<para>To verify that it is actually working, use
 +	  <application>dig</application> to make a query for a signed zone
 +	  using the resolver just configured.  A successful reply will contain
 +	  the <literal>AD</literal> flag to indicate the data was
 +	  authenticated.  Running a query such as
 +	  <screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
 +	  should return the <acronym>DS</acronym> <acronym>RR</acronym> for
 +	  the .se zone.  In the <literal>flags:</literal> section the
 +	  <literal>AD</literal> flag should be set, as seen
 +	  in:<programlisting>
 +...
 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 +...
 +	  </programlisting>  This means that the resolver is now capable of
 +	  authenticating <acronym>DNS</acronym> queries.</para>
 +      </sect3>
 +
 +      <sect3 id="dns-dnssec-auth">
 +        <title>Authoritative <acronym>DNS</acronym> server configuration</title>
 +        <para>In order to get an authoritative nameserver to serve a
 +          <acronym>DNSSEC</acronym> signed zone, a little more work is
 +          required.  To sign a zone, two cryptographic keys for that zone must
 +          be generated. These two keys are usually called the Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>) and Zone Signing Key
 +          (<acronym role="Zone Signing Key">ZSK</acronym>) respectively.  The
 +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 +          of authority to the data in need of validation and as such is also
 +          called a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>) key.  This key
 +          needs to be published in the parent zone as well, to establish the
 +          trust chain.  How this is accomplished depends on the parent zone
 +          owner. The <acronym role="Zone Signing Key">ZSK</acronym> is used
 +          to sign the zone, and only needs to be published there.</para>
 +
 +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 +          role="domainname">example.com</hostid> zone depicted in previous
 +          examples, the first step is to use
 +          <application>dnssec-keygen</application> to generate the
 +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> keypair.  This keypair
 +          can utilize different cryptograhic algorithms.  Currently the mandatory
 +          algorithm is <literal>RSA/SHA-1</literal>.  In the examples the key
 +          length used is 2048 bits for the <acronym>KSK</acronym> and 1024 bits
 +          for the <acronym>ZSK</acronym>.  To generate the
 +          <acronym>KSK</acronym> for <hostid
 +          role="domainname">example.com</hostid>, run
 +          <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.com</userinput></screen>
 +          and to generate the
 +          <acronym>ZSK</acronym>, run
 +          <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com</userinput></screen>
 +          <application>dnssec-keygen</application> outputs two files, the public
 +          and the private keys in files named similar to
 +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 +          Keep track of which key ID belongs to which key.  This is especially
 +          important when having more than one key in a zone.  The public key
 +          files can now be included in the zone file, using the
 +          <literal>$include</literal> statement. It should look something like
 +          this:<programlisting>
 +$include Kexample.net.+005+nnnnn.key    ; ZSK
 +$include Kexample.net.+005+nnnnn.key    ; KSK
 +	  </programlisting></para>
 +
 +	<para>Finally, sign the zone and tell <acronym>BIND</acronym> to use
 +	  the signed zonefile.  To sign a zone
 +	  <application>dnssec-signzone</application> is used.  The command to
 +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 +	  <filename>example.com.db</filename> would look similar to
 +	  <screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com+005+nnnnn example.com.db Kexample.com+005+nnnnn.key</userinput></screen>
 +	  The key supplied to
 +	  the <option>-k</option> argument is the <acronym>KSK</acronym> and
 +	  the other key file is the <acronym>ZSK</acronym> that should be used
 +	  in the signing.  It is possible to supply more than one
 +	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, which will result
 +	  in the zone being signed with all supplied keys.  This can be needed
 +	  to supply zone data signed using more than one algorithm.  The output
 +	  of <application>dnssec-signzone</application> is a zone file with all
 +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 +	  the extension <literal>.signed</literal>, such as
 +	  <filename>example.com.db.signed</filename>.  To use this signed zone
 +	  just modify the zone directive in <filename>named.conf</filename> to
 +	  use this file.  By default, the signatures are only valid 30 days,
 +	  meaning that the zone needs to be resigned within this time.  It is
 +	  possible to make a script and a cron job to do this.  See relevant
 +	  manuals for details.</para>
 +
 +	<para>Some cautionary words at the end.  Be sure to keep private keys
 +	  confidential, as with all cryptographic keys.  When changing a key it
 +	  is best to include the new key into the zone, while still signing with
 +	  the old key, and then move over to using the new key to sign.  After
 +	  these steps are done the old key can be removed from the zone.
 +	  Failiure to do this might render the <acronym>DNS</acronym> data
 +	  unavailable for a time, until the new key has propagated through the
 +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 +	  <ulink
 +	  url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> 4641:
 +	  <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>
 +      </sect3>
 +
 +      <sect3>
 +        <title>Automation using <acronym>BIND</acronym> 9.7 or later</title>
 +        <para>Beginning with <acronym>BIND</acronym> version 9.7, a new feature
 +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 +          feature aims to make the key management and signing process simpler by
 +          automating parts of the task.  By putting the keys into a directory
 +          called a <emphasis>key repository</emphasis>, and using the new option
 +          <literal>auto-dnssec</literal>, it is possible to create a dynamic zone
 +          which will be resigned as needed.  To update this zone use
 +          <application>nsupdate</application> with the new option
 +          <option>-l</option>. <application>rndc</application> has
 +          also grown the ability to sign zones with keys in the key repository,
 +          using the option <option>sign</option>.  To tell
 +          <acronym>BIND</acronym> to use this automatic signing and zone
 +          updating for <hostid role="domainname">exanple.com</hostid>, add the
 +          following to <filename>named.conf</filename>:<programlisting>
 +zone example.com {
 +	type master;
 +	key-directory "keys";
 +	update-policy local;
 +	auto-dnssec maintain;
 +	file "dynamic/example.com.zone";
 +};
 +	  </programlisting> After making these changes, generate keys for the
 +	  zone as explained in <xref linkend="dns-dnssec-auth">, put those keys
 +	  in the key repository given as the argument to the
 +	  <literal>key-directory</literal> in the zone configuration and sign
 +	  the zone using <application>rndc</application>.  Updates to a zone
 +	  configured this way must be done using
 +	  <application>nsupdate</application>, which will take care of
 +	  re-signing the zone with the new data added.  For further details,
 +	  see <xref linkend="dns-read"> and the <acronym>BIND</acronym>
 +	  documentation.</para>
 +	</sect3>
 +
 +    </sect2>
 +
 +    <sect2>
        <title>Security</title>
  
        <para>Although BIND is the most common implementation of DNS,
 @@ -3897,11 +4183,12 @@
        </tip>
      </sect2>
  
 -    <sect2>
 +    <sect2 id="dns-read">
        <title>Further Reading</title>
  
        <para>BIND/<application>named</application> manual pages:
 -      &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>
 @@ -3932,6 +4219,38 @@
  	      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
 +	      - Recource 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">RFC 5011
 +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 +	      Trust Anchors</ulink></para>
 +	</listitem>
 +
        </itemizedlist>
      </sect2>
    </sect1>
 Index: share/sgml/man-refs.ent
 ===================================================================
 RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v
 retrieving revision 1.511
 diff -u -d -r1.511 man-refs.ent
 --- share/sgml/man-refs.ent	11 Feb 2011 16:15:44 -0000	1.511
 +++ share/sgml/man-refs.ent	22 May 2011 22:50:40 -0000
 @@ -4257,6 +4257,8 @@
  <!ENTITY man.diskpart.8 "<citerefentry/<refentrytitle/diskpart/<manvolnum/8//">
  <!ENTITY man.dm.8 "<citerefentry/<refentrytitle/dm/<manvolnum/8//">
  <!ENTITY man.dmesg.8 "<citerefentry/<refentrytitle/dmesg/<manvolnum/8//">
 +<!ENTITY man.dnssec-keygen.8 "<citerefentry/<refentrytitle/dnssec-keygen<manvolnum/8//">
 +<!ENTITY man.dnssec-signzone.8 "<citerefentry/<refentrytitle/dnssec-signzone<manvolnum/8//">
  <!ENTITY man.dump.8 "<citerefentry/<refentrytitle/dump/<manvolnum/8//">
  <!ENTITY man.dumpfs.8 "<citerefentry/<refentrytitle/dumpfs/<manvolnum/8//">
  <!ENTITY man.dumpon.8 "<citerefentry/<refentrytitle/dumpon/<manvolnum/8//">
 
 --------------040500050509000704050409--

From: Niclas Zeising <niclas.zeising@gmail.com>
To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com
Cc:  
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Mon, 23 May 2011 14:46:30 +0200

 This is a multi-part message in MIME format.
 --------------090906090406000801020902
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 After comments from Doug Barton and more comments from Warren Block,
 here is a further refined patch with some changes and spelling fixes.
 It also contains the necessary changes to man-refs.ent.
 
 Thank you for the help and review!
 -- 
 Niclas
 
 --------------090906090406000801020902
 Content-Type: text/plain;
  name="network-servers.chapter.sgml.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="network-servers.chapter.sgml.diff"
 
 Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 retrieving revision 1.130
 diff -u -d -r1.130 chapter.sgml
 --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	15 May 2011 20:41:30 -0000	1.130
 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	23 May 2011 12:10:10 -0000
 @@ -3872,6 +3872,325 @@
      </sect2>
  
      <sect2>
 +      <title><acronym role="Doman Name Security Extensions">DNSSEC</acronym></title>
 +      <indexterm>
 +        <primary>BIND</primary>
 +        <secondary>DNS security extensions</secondary>
 +      </indexterm>
 +
 +      <para>Domain Name System Security Extensions, or
 +        <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	for short, is a suite of specifications to protect
 +	resolving name servers from forged <acronym>DNS</acronym> data,
 +	such as spoofed <acronym>DNS</acronym> records.  By using digital
 +	signatures, a resolver can verify the integrity of the record.  Note 
 +	that <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	only provides integrity via digitally signing the Resource Records
 +	(<acronym role="Resource Record">RR</acronym>s).  It provides neither
 +	confidentiality nor protection against false end-user assumptions.
 +	This means that it cannot protect against people going to
 +	<hostid role="domainname">example.net</hostid> instead of
 +	<hostid role="domainname">example.com</hostid>.  The only 
 +	thing <acronym>DNSSEC</acronym> does is authenticate that the data 
 +	has not been compromised in transit. 
 +	The security of <acronym>DNS</acronym> is an important step in 
 +	securing the Internet in general.  For more in-depth details of how 
 +	<acronym>DNSSEC</acronym> works, the relevant
 +	<acronym>RFC</acronym>s are a good place to start.  See the list in
 +	<xref linkend="dns-read">.</para>
 +
 +      <para>The following sections will demonstrate how to enable
 +	<acronym>DNSSEC</acronym> for an authoritative <acronym>DNS</acronym>
 +	server and a recursive (or caching) <acronym>DNS</acronym> server
 +	running <acronym>BIND</acronym> 9.  While all versions of
 +	<acronym>BIND</acronym> 9 support <acronym>DNSSEC</acronym>, it is
 +	necessary to have at least version 9.6.2 in order to be able to use
 +	the signed root zone when validating <acronym>DNS</acronym> queries.
 +	This is because earlier versions lack the required algorithms to enable
 +	validation using the root zone key.  It is strongly recommended to use
 +	the latest version of <acronym>BIND</acronym> 9.7 or later to take
 +	advantage of automatic key updating for the root key, as well as other
 +	features to automatically keep zones signed and signatures up to date.
 +	Where configurations differ between 9.6.2 and 9.7 and later,
 +	differences will be pointed out.</para>
 +
 +      <sect3>
 +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>Enabling <acronym>DNSSEC</acronym> validation of queries
 +	  performed by a recursive <acronym>DNS</acronym> server requires a
 +	  few changes to <filename>named.conf</filename>.  Before making these
 +	  changes the root zone key, or trust anchor, must be acquired.
 +	  Currently the root zone key is not available in a file format
 +	  <acronym>BIND</acronym> understands, so it has to be manually
 +	  converted into the proper format.  The key itself can be obtained by
 +	  querying the root zone for it using <application>dig</application>.
 +	  By running
 +	  <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . &gt; root.dnskey</userinput></screen>
 +	  the key will end up in <filename>root.dnskey</filename>. The
 +	  contents should look something like this:</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>Do not be alarmed if the obtained keys differ from this example.
 +          They might have changed since these instructions were last updated.
 +          This output actually contains two keys.  The first key in the
 +          listing, with the value 257 after the DNSKEY record type, is the one
 +          needed. This value indicates that this is a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>),
 +          commonly known as a Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>). The second key,
 +          with value 256, is a subordinate key, commonly called a Zone Signing
 +          Key (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 +          different key types later in the <xref linkend="dns-dnssec-auth">.
 +        </para>
 +
 +        <para>Now the key must be verified and formatted so that
 +          <acronym>BIND</acronym> can use it.  To verify the key, generate a
 +          <acronym role="Delegation Signer">DS</acronym> 
 +          <acronym role="Resource Record">RR</acronym> set.  Create a file
 +          containing these <acronym role="Resource Record">RR</acronym>s with 
 +          <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . &gt; root.ds</userinput></screen>
 +          These records use SHA-1 and SHA-256 respectively, and should look
 +          similar to the following example, where the longer is using SHA-256.
 +        </para>
 +
 +        <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
 +
 +	<para>The SHA-256 <acronym>RR</acronym> can now be compared to the
 +	  digest in <ulink url="https://data.iana.org/root-anchors/root-anchors.xml">
 +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 +	  absolutely sure that the key has not been tampered with the data in
 +	  the <acronym>XML</acronym> file can be verified using the
 +	  <acronym>PGP</acronym> signature in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 +	    
 +	<para>Next, the key must be formatted properly.  This differs a
 +	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and
 +	  later.  In version 9.7 support was added to automatically track
 +	  changes to the key and update it as necessary.  This is done using
 +	  <literal>managed-keys</literal> as seen in the example below.
 +	  When using the older version, the key is added using a
 +	  <literal>trusted-keys</literal> statement and updates must be done
 +	  manually.  For <acronym>BIND</acronym> 9.6.2 the format should look
 +	  like:</para>
 +
 +	<programlisting>trusted-keys {
 +	"." 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};</programlisting>
 +
 +	<para>For 9.7 the format will instead be:</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>The root key can now be added to <filename>named.conf</filename>
 +	  either directly or by including a file containing the key.  After
 +	  these steps, configure <acronym>BIND</acronym> to do
 +	  <acronym>DNSSEC</acronym> validation on queries by editing
 +	  <filename>named.conf</filename> and adding the following to the
 +	  <literal>options</literal> directive:</para>
 +
 +	  <programlisting>dnssec-enable yes;
 +dnssec-validation yes;</programlisting>
 +
 +	<para>To verify that it is actually working use
 +	  <application>dig</application> to make a query for a signed zone
 +	  using the resolver just configured.  A successful reply will contain
 +	  the <literal>AD</literal> flag to indicate the data was
 +	  authenticated.  Running a query such as
 +	  <screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
 +	  should return the <acronym>DS</acronym> <acronym>RR</acronym> for
 +	  the <literal>.se</literal> zone.  In the <literal>flags:</literal>
 +	  section the <literal>AD</literal> flag should be set, as seen in:
 +	</para>
 +
 +	  <programlisting>...
 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 +...</programlisting>
 +
 +	<para>The resolver is now capable of authenticating
 +	  <acronym>DNS</acronym> queries.</para>
 +      </sect3>
 +
 +      <sect3 id="dns-dnssec-auth">
 +        <title>Authoritative <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>In order to get an authoritative name server to serve a
 +	  <acronym>DNSSEC</acronym> signed zone a little more work is
 +	  required.  A zone is signed using cryptographic keys which must be
 +	  generated.  It is possible to use only one key for this. The 
 +	  preferred method however is to have a strong well-protected Key Signing Key
 +	  (<acronym role="Key Signing Key">KSK</acronym>) that is not rotated
 +	  very often and a Zone Signing Key
 +	  (<acronym role="Zone Signing Key">ZSK</acronym>) that is rotated more
 +	  frequently.  Information on recommended operational practices can be
 +	  found in <ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational 
 +	  Practices</ulink>.  Practices regarding the root zone can be found 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> and
 +	  <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>. The
 +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 +          of authority to the data in need of validation and as such is also
 +          called a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>) key.  A message
 +          digest of this key, called a Delegation Signer
 +          (<acronym role="Delegation Signer">DS</acronym>) record, must be
 +          published in the parent zone to establish the trust chain.  How
 +          this is accomplished depends on the parent zone owner.  The
 +          <acronym role="Zone Signing Key">ZSK</acronym> is used
 +          to sign the zone, and only needs to be published there.</para>
 +
 +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 +          role="domainname">example.com</hostid> zone depicted in previous
 +          examples, the first step is to use
 +          <application>dnssec-keygen</application> to generate the
 +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> key pair.  This
 +          key pair can utilize different cryptographic algorithms.  It is
 +          recommended to use RSA/SHA256 for the keys and 2048 bits key length
 +          should be enough. To generate the <acronym>KSK</acronym> for
 +          <hostid role="domainname">example.com</hostid>, run
 +          <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +          and to generate the
 +          <acronym>ZSK</acronym>, run
 +          <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +          <application>dnssec-keygen</application> outputs two files, the public
 +          and the private keys in files named similar to
 +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 +          Keep track of which key ID belongs to which key.  This is especially
 +          important when having more than one key in a zone.  It is also
 +          possible to rename the keys.  For each <acronym>KSK</acronym> file do:
 +          <screen>&prompt.user; <userinput>mv Kexample.com+005+nnnnn.key Kexample.com+005+nnnnn.KSK.key</userinput>
 +          &prompt.user; <userinput>mv Kexample.com+005+nnnnn.private Kexample.com+005+nnnnn.KSK.private</userinput></screen>
 +          For the <acronym>ZSK</acronym> files, substitute
 +          <literal>KSK</literal> for <literal>ZSK</literal> as necessary.  The
 +          files can now be included in the zone file, using the
 +          <literal>$include</literal> statement. It should look something like
 +          this:</para>
 +
 +	<programlisting>$include Kexample.com.+005+nnnnn.KSK.key    ; ZSK
 +$include Kexample.com.+005+nnnnn.ZSK.key    ; KSK</programlisting>
 +
 +	<para>Finally, sign the zone and tell <acronym>BIND</acronym> to use
 +	  the signed zone file.  To sign a zone
 +	  <application>dnssec-signzone</application> is used.  The command to
 +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 +	  <filename>example.com.db</filename> would look similar to
 +	  <screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com+005+nnnnn.KSK example.com.db Kexample.com+005+nnnnn.ZSK.key</userinput></screen>
 +	  The key supplied to
 +	  the <option>-k</option> argument is the <acronym>KSK</acronym> and
 +	  the other key file is the <acronym>ZSK</acronym> that should be used
 +	  in the signing.  It is possible to supply more than one
 +	  <acronym>KSK</acronym> and <acronym>ZSK</acronym>, which will result
 +	  in the zone being signed with all supplied keys.  This can be needed
 +	  to supply zone data signed using more than one algorithm.  The output
 +	  of <application>dnssec-signzone</application> is a zone file with all
 +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 +	  the extension <literal>.signed</literal>, such as
 +	  <filename>example.com.db.signed</filename>.  The
 +	  <acronym role="Delegation Signer">DS</acronym> records will also be
 +	  written to a separate file <filename>dsset-example.com</filename>.
 +	  To use this signed zone just modify the zone directive in
 +	  <filename>named.conf</filename> to use
 +	  <filename>example.com.db.signed</filename>.  By default, the
 +	  signatures are only valid 30 days, meaning that the zone needs to
 +	  be resigned in about 15 days to be sure that resolvers are not
 +	  caching records with stale signatures.  It is possible to make a
 +	  script and a cron job to do this.  See relevant manuals for details.
 +	</para>
 +
 +	<para>Be sure to keep private keys confidential, as with all
 +	  cryptographic keys.  When changing a key it is best to include the
 +	  new key into the zone, while still signing with
 +	  the old one, and then move over to using the new key to sign.  After
 +	  these steps are done the old key can be removed from the zone.
 +	  Failure to do this might render the <acronym>DNS</acronym> data
 +	  unavailable for a time, until the new key has propagated through the
 +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 +	  <ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational
 +	  practices</ulink>.</para>
 +      </sect3>
 +
 +      <sect3>
 +        <title>Automation using <acronym>BIND</acronym> 9.7 or later</title>
 +        <para>Beginning with <acronym>BIND</acronym> version 9.7 a new feature
 +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 +          feature aims to make the key management and signing process simpler by
 +          automating parts of the task.  By putting the keys into a directory
 +          called a <emphasis>key repository</emphasis>, and using the new option
 +          <literal>auto-dnssec</literal>, it is possible to create a dynamic zone
 +          which will be resigned as needed.  To update this zone use
 +          <application>nsupdate</application> with the new option
 +          <option>-l</option>. <application>rndc</application> has
 +          also grown the ability to sign zones with keys in the key repository,
 +          using the option <option>sign</option>.  To tell
 +          <acronym>BIND</acronym> to use this automatic signing and zone
 +          updating for <hostid role="domainname">example.com</hostid>, add the
 +          following to <filename>named.conf</filename>:</para>
 +
 +	<programlisting>zone example.com {
 +	type master;
 +	key-directory "/etc/named/keys";
 +	update-policy local;
 +	auto-dnssec maintain;
 +	file "/etc/named/dynamic/example.com.zone";
 +};</programlisting> 
 +
 +	<para>After making these changes, generate keys for the zone as
 +	  explained in <xref linkend="dns-dnssec-auth">, put those keys
 +	  in the key repository given as the argument to the
 +	  <literal>key-directory</literal> in the zone configuration and the
 +	  zone will be signed automatically.  Updates to a zone configured
 +	  this way must be done using
 +	  <application>nsupdate</application>, which will take care of
 +	  re-signing the zone with the new data added.  For further details,
 +	  see <xref linkend="dns-read"> and the <acronym>BIND</acronym>
 +	  documentation.</para>
 +	</sect3>
 +
 +    </sect2>
 +
 +    <sect2>
        <title>Security</title>
  
        <para>Although BIND is the most common implementation of DNS,
 @@ -3897,11 +4216,12 @@
        </tip>
      </sect2>
  
 -    <sect2>
 +    <sect2 id="dns-read">
        <title>Further Reading</title>
  
        <para>BIND/<application>named</application> manual pages:
 -      &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>
 @@ -3922,6 +4242,17 @@
  	</listitem>
  
  	<listitem>
 +	  <para><ulink url="http://www.root-dnssec.org/documentation/"> Root
 +	      <acronym>DNSSEC</acronym></ulink></para>
 +	</listitem>
 +
 +	<listitem>
 +	  <para><ulink 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 Facilities</ulink></para>
 @@ -3932,6 +4263,38 @@
  	      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">RFC 5011
 +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 +	      Trust Anchors</ulink></para>
 +	</listitem>
 +
        </itemizedlist>
      </sect2>
    </sect1>
 Index: share/sgml/man-refs.ent
 ===================================================================
 RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v
 retrieving revision 1.511
 diff -u -d -r1.511 man-refs.ent
 --- share/sgml/man-refs.ent	11 Feb 2011 16:15:44 -0000	1.511
 +++ share/sgml/man-refs.ent	23 May 2011 12:10:56 -0000
 @@ -4257,6 +4257,8 @@
  <!ENTITY man.diskpart.8 "<citerefentry/<refentrytitle/diskpart/<manvolnum/8//">
  <!ENTITY man.dm.8 "<citerefentry/<refentrytitle/dm/<manvolnum/8//">
  <!ENTITY man.dmesg.8 "<citerefentry/<refentrytitle/dmesg/<manvolnum/8//">
 +<!ENTITY man.dnssec-keygen.8 "<citerefentry/<refentrytitle/dnssec-keygen<manvolnum/8//">
 +<!ENTITY man.dnssec-signzone.8 "<citerefentry/<refentrytitle/dnssec-signzone<manvolnum/8//">
  <!ENTITY man.dump.8 "<citerefentry/<refentrytitle/dump/<manvolnum/8//">
  <!ENTITY man.dumpfs.8 "<citerefentry/<refentrytitle/dumpfs/<manvolnum/8//">
  <!ENTITY man.dumpon.8 "<citerefentry/<refentrytitle/dumpon/<manvolnum/8//">
 
 --------------090906090406000801020902--
Responsible-Changed-From-To: freebsd-doc->bcr 
Responsible-Changed-By: bcr 
Responsible-Changed-When: Tue May 24 09:27:27 UTC 2011 
Responsible-Changed-Why:  
Grab this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157245 

From: Niclas Zeising <niclas.zeising@gmail.com>
To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com
Cc:  
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Tue, 24 May 2011 18:29:20 +0200

 This is a multi-part message in MIME format.
 --------------060709040109030203000004
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 Here is another patch. This patch just contains some whitespace fixes
 and puts <screen></screen> outside <para></para>.
 Regards!
 -- 
 Niclas
 
 --------------060709040109030203000004
 Content-Type: text/plain;
  name="network-servers.chapter.sgml.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="network-servers.chapter.sgml.diff"
 
 Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 retrieving revision 1.131
 diff -u -d -r1.131 chapter.sgml
 --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	23 May 2011 15:32:34 -0000	1.131
 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	23 May 2011 17:21:25 -0000
 @@ -3872,6 +3872,340 @@
      </sect2>
  
      <sect2>
 +      <title><acronym role="Doman Name Security Extensions">DNSSEC</acronym></title>
 +      <indexterm>
 +        <primary>BIND</primary>
 +        <secondary>DNS security extensions</secondary>
 +      </indexterm>
 +
 +      <para>Domain Name System Security Extensions, or
 +        <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	for short, is a suite of specifications to protect
 +	resolving name servers from forged <acronym>DNS</acronym> data,
 +	such as spoofed <acronym>DNS</acronym> records.  By using digital
 +	signatures, a resolver can verify the integrity of the record.  Note 
 +	that <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	only provides integrity via digitally signing the Resource Records
 +	(<acronym role="Resource Record">RR</acronym>s).  It provides neither
 +	confidentiality nor protection against false end-user assumptions.
 +	This means that it cannot protect against people going to
 +	<hostid role="domainname">example.net</hostid> instead of
 +	<hostid role="domainname">example.com</hostid>.  The only 
 +	thing <acronym>DNSSEC</acronym> does is authenticate that the data 
 +	has not been compromised in transit. 
 +	The security of <acronym>DNS</acronym> is an important step in 
 +	securing the Internet in general.  For more in-depth details of how 
 +	<acronym>DNSSEC</acronym> works, the relevant
 +	<acronym>RFC</acronym>s are a good place to start.  See the list in
 +	<xref linkend="dns-read">.</para>
 +
 +      <para>The following sections will demonstrate how to enable
 +	<acronym>DNSSEC</acronym> for an authoritative <acronym>DNS</acronym>
 +	server and a recursive (or caching) <acronym>DNS</acronym> server
 +	running <acronym>BIND</acronym> 9.  While all versions of
 +	<acronym>BIND</acronym> 9 support <acronym>DNSSEC</acronym>, it is
 +	necessary to have at least version 9.6.2 in order to be able to use
 +	the signed root zone when validating <acronym>DNS</acronym> queries.
 +	This is because earlier versions lack the required algorithms to enable
 +	validation using the root zone key.  It is strongly recommended to use
 +	the latest version of <acronym>BIND</acronym> 9.7 or later to take
 +	advantage of automatic key updating for the root key, as well as other
 +	features to automatically keep zones signed and signatures up to date.
 +	Where configurations differ between 9.6.2 and 9.7 and later,
 +	differences will be pointed out.</para>
 +
 +      <sect3>
 +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>Enabling <acronym>DNSSEC</acronym> validation of queries
 +	  performed by a recursive <acronym>DNS</acronym> server requires a
 +	  few changes to <filename>named.conf</filename>.  Before making these
 +	  changes the root zone key, or trust anchor, must be acquired.
 +	  Currently the root zone key is not available in a file format
 +	  <acronym>BIND</acronym> understands, so it has to be manually
 +	  converted into the proper format.  The key itself can be obtained by
 +	  querying the root zone for it using <application>dig</application>.
 +	  By running</para>
 +
 +	<screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . &gt; root.dnskey</userinput></screen>
 +
 +	<para>the key will end up in <filename>root.dnskey</filename>. The
 +	  contents should look something like this:</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>Do not be alarmed if the obtained keys differ from this example.
 +          They might have changed since these instructions were last updated.
 +          This output actually contains two keys.  The first key in the
 +          listing, with the value 257 after the DNSKEY record type, is the one
 +          needed. This value indicates that this is a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>),
 +          commonly known as a Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>). The second key,
 +          with value 256, is a subordinate key, commonly called a Zone Signing
 +          Key (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 +          different key types later in the <xref linkend="dns-dnssec-auth">.
 +        </para>
 +
 +        <para>Now the key must be verified and formatted so that
 +          <acronym>BIND</acronym> can use it.  To verify the key, generate a
 +          <acronym role="Delegation Signer">DS</acronym> 
 +          <acronym role="Resource Record">RR</acronym> set.  Create a file
 +          containing these <acronym role="Resource Record">RR</acronym>s with
 +        </para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . &gt; root.ds</userinput></screen>
 +
 +        <para>These records use SHA-1 and SHA-256 respectively, and should
 +          look similar to the following example, where the longer is using
 +          SHA-256.</para>
 +
 +        <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
 +
 +	<para>The SHA-256 <acronym>RR</acronym> can now be compared to the
 +	  digest in <ulink url="https://data.iana.org/root-anchors/root-anchors.xml">
 +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 +	  absolutely sure that the key has not been tampered with the data in
 +	  the <acronym>XML</acronym> file can be verified using the
 +	  <acronym>PGP</acronym> signature in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 +	    
 +	<para>Next, the key must be formatted properly.  This differs a
 +	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and
 +	  later.  In version 9.7 support was added to automatically track
 +	  changes to the key and update it as necessary.  This is done using
 +	  <literal>managed-keys</literal> as seen in the example below.
 +	  When using the older version, the key is added using a
 +	  <literal>trusted-keys</literal> statement and updates must be done
 +	  manually.  For <acronym>BIND</acronym> 9.6.2 the format should look
 +	  like:</para>
 +
 +	<programlisting>trusted-keys {
 +	"." 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};</programlisting>
 +
 +	<para>For 9.7 the format will instead be:</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>The root key can now be added to <filename>named.conf</filename>
 +	  either directly or by including a file containing the key.  After
 +	  these steps, configure <acronym>BIND</acronym> to do
 +	  <acronym>DNSSEC</acronym> validation on queries by editing
 +	  <filename>named.conf</filename> and adding the following to the
 +	  <literal>options</literal> directive:</para>
 +
 +	  <programlisting>dnssec-enable yes;
 +dnssec-validation yes;</programlisting>
 +
 +	<para>To verify that it is actually working use
 +	  <application>dig</application> to make a query for a signed zone
 +	  using the resolver just configured.  A successful reply will contain
 +	  the <literal>AD</literal> flag to indicate the data was
 +	  authenticated.  Running a query such as</para>
 +
 +	<screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
 +
 +	<para>should return the <acronym>DS</acronym> <acronym>RR</acronym>
 +	  for the <literal>.se</literal> zone.  In the
 +	  <literal>flags:</literal> section the <literal>AD</literal> flag
 +	  should be set, as seen in:</para>
 +
 +	<programlisting>...
 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 +...</programlisting>
 +
 +	<para>The resolver is now capable of authenticating
 +	  <acronym>DNS</acronym> queries.</para>
 +      </sect3>
 +
 +      <sect3 id="dns-dnssec-auth">
 +        <title>Authoritative <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>In order to get an authoritative name server to serve a
 +	  <acronym>DNSSEC</acronym> signed zone a little more work is
 +	  required.  A zone is signed using cryptographic keys which must be
 +	  generated.  It is possible to use only one key for this. The 
 +	  preferred method however is to have a strong well-protected Key Signing Key
 +	  (<acronym role="Key Signing Key">KSK</acronym>) that is not rotated
 +	  very often and a Zone Signing Key
 +	  (<acronym role="Zone Signing Key">ZSK</acronym>) that is rotated more
 +	  frequently.  Information on recommended operational practices can be
 +	  found in <ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational 
 +	  Practices</ulink>.  Practices regarding the root zone can be found 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> and
 +	  <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>. The
 +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 +          of authority to the data in need of validation and as such is also
 +          called a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>) key.  A message
 +          digest of this key, called a Delegation Signer
 +          (<acronym role="Delegation Signer">DS</acronym>) record, must be
 +          published in the parent zone to establish the trust chain.  How
 +          this is accomplished depends on the parent zone owner.  The
 +          <acronym role="Zone Signing Key">ZSK</acronym> is used
 +          to sign the zone, and only needs to be published there.</para>
 +
 +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 +          role="domainname">example.com</hostid> zone depicted in previous
 +          examples, the first step is to use
 +          <application>dnssec-keygen</application> to generate the
 +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> key pair.  This
 +          key pair can utilize different cryptographic algorithms.  It is
 +          recommended to use RSA/SHA256 for the keys and 2048 bits key length
 +          should be enough. To generate the <acronym>KSK</acronym> for
 +          <hostid role="domainname">example.com</hostid>, run</para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +
 +        <para>and to generate the <acronym>ZSK</acronym>, run</para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +
 +        <para><application>dnssec-keygen</application> outputs two files, the
 +          public and the private keys in files named similar to
 +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 +          Keep track of which key ID belongs to which key.  This is especially
 +          important when having more than one key in a zone.  It is also
 +          possible to rename the keys.  For each <acronym>KSK</acronym> file
 +          do:</para>
 +
 +        <screen>&prompt.user; <userinput>mv Kexample.com+005+nnnnn.key Kexample.com+005+nnnnn.KSK.key</userinput>
 +          &prompt.user; <userinput>mv Kexample.com+005+nnnnn.private Kexample.com+005+nnnnn.KSK.private</userinput></screen>
 +
 +        <para>For the <acronym>ZSK</acronym> files, substitute
 +          <literal>KSK</literal> for <literal>ZSK</literal> as necessary.  The
 +          files can now be included in the zone file, using the
 +          <literal>$include</literal> statement. It should look something like
 +          this:</para>
 +
 +	<programlisting>$include Kexample.com.+005+nnnnn.KSK.key    ; ZSK
 +$include Kexample.com.+005+nnnnn.ZSK.key    ; KSK</programlisting>
 +
 +	<para>Finally, sign the zone and tell <acronym>BIND</acronym> to use
 +	  the signed zone file.  To sign a zone
 +	  <application>dnssec-signzone</application> is used.  The command to
 +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 +	  <filename>example.com.db</filename> would look similar to</para>
 +
 +	<screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com+005+nnnnn.KSK example.com.db Kexample.com+005+nnnnn.ZSK.key</userinput></screen>
 +
 +	<para>The key supplied to the <option>-k</option> argument is the
 +	  <acronym>KSK</acronym> and the other key file is the
 +	  <acronym>ZSK</acronym> that should be used in the signing.  It is
 +	  possible to supply more than one <acronym>KSK</acronym> and
 +	  <acronym>ZSK</acronym>, which will result in the zone being signed
 +	  with all supplied keys.  This can be needed to supply zone data
 +	  signed using more than one algorithm.  The output of
 +	  <application>dnssec-signzone</application> is a zone file with all
 +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 +	  the extension <literal>.signed</literal>, such as
 +	  <filename>example.com.db.signed</filename>.  The
 +	  <acronym role="Delegation Signer">DS</acronym> records will also be
 +	  written to a separate file <filename>dsset-example.com</filename>.
 +	  To use this signed zone just modify the zone directive in
 +	  <filename>named.conf</filename> to use
 +	  <filename>example.com.db.signed</filename>.  By default, the
 +	  signatures are only valid 30 days, meaning that the zone needs to
 +	  be resigned in about 15 days to be sure that resolvers are not
 +	  caching records with stale signatures.  It is possible to make a
 +	  script and a cron job to do this.  See relevant manuals for details.
 +	</para>
 +
 +	<para>Be sure to keep private keys confidential, as with all
 +	  cryptographic keys.  When changing a key it is best to include the
 +	  new key into the zone, while still signing with
 +	  the old one, and then move over to using the new key to sign.  After
 +	  these steps are done the old key can be removed from the zone.
 +	  Failure to do this might render the <acronym>DNS</acronym> data
 +	  unavailable for a time, until the new key has propagated through the
 +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 +	  <ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational
 +	  practices</ulink>.</para>
 +      </sect3>
 +
 +      <sect3>
 +        <title>Automation using <acronym>BIND</acronym> 9.7 or later</title>
 +        <para>Beginning with <acronym>BIND</acronym> version 9.7 a new feature
 +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 +          feature aims to make the key management and signing process simpler by
 +          automating parts of the task.  By putting the keys into a directory
 +          called a <emphasis>key repository</emphasis>, and using the new option
 +          <literal>auto-dnssec</literal>, it is possible to create a dynamic zone
 +          which will be resigned as needed.  To update this zone use
 +          <application>nsupdate</application> with the new option
 +          <option>-l</option>. <application>rndc</application> has
 +          also grown the ability to sign zones with keys in the key repository,
 +          using the option <option>sign</option>.  To tell
 +          <acronym>BIND</acronym> to use this automatic signing and zone
 +          updating for <hostid role="domainname">example.com</hostid>, add the
 +          following to <filename>named.conf</filename>:</para>
 +
 +	<programlisting>zone example.com {
 +	type master;
 +	key-directory "/etc/named/keys";
 +	update-policy local;
 +	auto-dnssec maintain;
 +	file "/etc/named/dynamic/example.com.zone";
 +};</programlisting> 
 +
 +	<para>After making these changes, generate keys for the zone as
 +	  explained in <xref linkend="dns-dnssec-auth">, put those keys
 +	  in the key repository given as the argument to the
 +	  <literal>key-directory</literal> in the zone configuration and the
 +	  zone will be signed automatically.  Updates to a zone configured
 +	  this way must be done using
 +	  <application>nsupdate</application>, which will take care of
 +	  re-signing the zone with the new data added.  For further details,
 +	  see <xref linkend="dns-read"> and the <acronym>BIND</acronym>
 +	  documentation.</para>
 +	</sect3>
 +
 +    </sect2>
 +
 +    <sect2>
        <title>Security</title>
  
        <para>Although BIND is the most common implementation of DNS,
 @@ -3897,11 +4231,12 @@
        </tip>
      </sect2>
  
 -    <sect2>
 +    <sect2 id="dns-read">
        <title>Further Reading</title>
  
        <para>BIND/<application>named</application> manual pages:
 -      &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>
 @@ -3922,6 +4257,17 @@
  	</listitem>
  
  	<listitem>
 +	  <para><ulink url="http://www.root-dnssec.org/documentation/"> Root
 +	      <acronym>DNSSEC</acronym></ulink></para>
 +	</listitem>
 +
 +	<listitem>
 +	  <para><ulink 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 Facilities</ulink></para>
 @@ -3932,6 +4278,38 @@
  	      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">RFC 5011
 +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 +	      Trust Anchors</ulink></para>
 +	</listitem>
 +
        </itemizedlist>
      </sect2>
    </sect1>
 Index: share/sgml/man-refs.ent
 ===================================================================
 RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v
 retrieving revision 1.511
 diff -u -d -r1.511 man-refs.ent
 --- share/sgml/man-refs.ent	11 Feb 2011 16:15:44 -0000	1.511
 +++ share/sgml/man-refs.ent	23 May 2011 17:22:07 -0000
 @@ -4257,6 +4257,8 @@
  <!ENTITY man.diskpart.8 "<citerefentry/<refentrytitle/diskpart/<manvolnum/8//">
  <!ENTITY man.dm.8 "<citerefentry/<refentrytitle/dm/<manvolnum/8//">
  <!ENTITY man.dmesg.8 "<citerefentry/<refentrytitle/dmesg/<manvolnum/8//">
 +<!ENTITY man.dnssec-keygen.8 "<citerefentry/<refentrytitle/dnssec-keygen<manvolnum/8//">
 +<!ENTITY man.dnssec-signzone.8 "<citerefentry/<refentrytitle/dnssec-signzone<manvolnum/8//">
  <!ENTITY man.dump.8 "<citerefentry/<refentrytitle/dump/<manvolnum/8//">
  <!ENTITY man.dumpfs.8 "<citerefentry/<refentrytitle/dumpfs/<manvolnum/8//">
  <!ENTITY man.dumpon.8 "<citerefentry/<refentrytitle/dumpon/<manvolnum/8//">
 
 --------------060709040109030203000004--

From: Doug Barton <dougb@FreeBSD.org>
To: Niclas Zeising <niclas.zeising@gmail.com>
Cc: freebsd-doc@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Tue, 24 May 2011 13:08:13 -0700

 Excellent work! :)  2 small nits remain, otherwise this looks good to go.
 
 On 05/23/2011 05:50, Niclas Zeising wrote:
 
 >   +	  found in<ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 
 The href should be http://tools.ietf.org/html/rfc4641 as they are in 
 29.6.10. The tools site has a much better overall viewing experience, 
 and more importantly gives clear indications if an RFC has been obsoleted.
 
 >   +	<programlisting>$include Kexample.com.+005+nnnnn.KSK.key    ; ZSK
 >   +$include Kexample.com.+005+nnnnn.ZSK.key    ; KSK</programlisting>
 
 The labels after the ;comment are reversed. The first should be KSK.
 
 
 hth,
 
 Doug
 
 -- 
 
 	Nothin' ever doesn't change, but nothin' changes much.
 			-- OK Go
 
 	Breadth of IT experience, and depth of knowledge in the DNS.
 	Yours for the right price.  :)  http://SupersetSolutions.com/
 

From: Niclas Zeising <niclas.zeising@gmail.com>
To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com
Cc:  
Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the
 DNS chapter in the handbook
Date: Tue, 24 May 2011 22:25:51 +0200

 This is a multi-part message in MIME format.
 --------------000703050907060405020802
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 Here is a another new patch which fixes two more things pointed out by
 dougb@. Hopefully this is the last one.
 Thanks for all help!
 -- 
 Niclas
 
 --------------000703050907060405020802
 Content-Type: text/plain;
  name="network-servers.chapter.sgml.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="network-servers.chapter.sgml.diff"
 
 Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v
 retrieving revision 1.131
 diff -u -d -r1.131 chapter.sgml
 --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	23 May 2011 15:32:34 -0000	1.131
 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml	24 May 2011 19:54:23 -0000
 @@ -3872,6 +3872,340 @@
      </sect2>
  
      <sect2>
 +      <title><acronym role="Doman Name Security Extensions">DNSSEC</acronym></title>
 +      <indexterm>
 +        <primary>BIND</primary>
 +        <secondary>DNS security extensions</secondary>
 +      </indexterm>
 +
 +      <para>Domain Name System Security Extensions, or
 +        <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	for short, is a suite of specifications to protect
 +	resolving name servers from forged <acronym>DNS</acronym> data,
 +	such as spoofed <acronym>DNS</acronym> records.  By using digital
 +	signatures, a resolver can verify the integrity of the record.  Note 
 +	that <acronym role="Domain Name Security Extensions">DNSSEC</acronym>
 +	only provides integrity via digitally signing the Resource Records
 +	(<acronym role="Resource Record">RR</acronym>s).  It provides neither
 +	confidentiality nor protection against false end-user assumptions.
 +	This means that it cannot protect against people going to
 +	<hostid role="domainname">example.net</hostid> instead of
 +	<hostid role="domainname">example.com</hostid>.  The only 
 +	thing <acronym>DNSSEC</acronym> does is authenticate that the data 
 +	has not been compromised in transit. 
 +	The security of <acronym>DNS</acronym> is an important step in 
 +	securing the Internet in general.  For more in-depth details of how 
 +	<acronym>DNSSEC</acronym> works, the relevant
 +	<acronym>RFC</acronym>s are a good place to start.  See the list in
 +	<xref linkend="dns-read">.</para>
 +
 +      <para>The following sections will demonstrate how to enable
 +	<acronym>DNSSEC</acronym> for an authoritative <acronym>DNS</acronym>
 +	server and a recursive (or caching) <acronym>DNS</acronym> server
 +	running <acronym>BIND</acronym> 9.  While all versions of
 +	<acronym>BIND</acronym> 9 support <acronym>DNSSEC</acronym>, it is
 +	necessary to have at least version 9.6.2 in order to be able to use
 +	the signed root zone when validating <acronym>DNS</acronym> queries.
 +	This is because earlier versions lack the required algorithms to enable
 +	validation using the root zone key.  It is strongly recommended to use
 +	the latest version of <acronym>BIND</acronym> 9.7 or later to take
 +	advantage of automatic key updating for the root key, as well as other
 +	features to automatically keep zones signed and signatures up to date.
 +	Where configurations differ between 9.6.2 and 9.7 and later,
 +	differences will be pointed out.</para>
 +
 +      <sect3>
 +	<title>Recursive <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>Enabling <acronym>DNSSEC</acronym> validation of queries
 +	  performed by a recursive <acronym>DNS</acronym> server requires a
 +	  few changes to <filename>named.conf</filename>.  Before making these
 +	  changes the root zone key, or trust anchor, must be acquired.
 +	  Currently the root zone key is not available in a file format
 +	  <acronym>BIND</acronym> understands, so it has to be manually
 +	  converted into the proper format.  The key itself can be obtained by
 +	  querying the root zone for it using <application>dig</application>.
 +	  By running</para>
 +
 +	<screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . &gt; root.dnskey</userinput></screen>
 +
 +	<para>the key will end up in <filename>root.dnskey</filename>. The
 +	  contents should look something like this:</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>Do not be alarmed if the obtained keys differ from this example.
 +          They might have changed since these instructions were last updated.
 +          This output actually contains two keys.  The first key in the
 +          listing, with the value 257 after the DNSKEY record type, is the one
 +          needed. This value indicates that this is a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>),
 +          commonly known as a Key Signing Key
 +          (<acronym role="Key Signing Key">KSK</acronym>). The second key,
 +          with value 256, is a subordinate key, commonly called a Zone Signing
 +          Key (<acronym role="Zone Signing Key">ZSK</acronym>).  More on the
 +          different key types later in the <xref linkend="dns-dnssec-auth">.
 +        </para>
 +
 +        <para>Now the key must be verified and formatted so that
 +          <acronym>BIND</acronym> can use it.  To verify the key, generate a
 +          <acronym role="Delegation Signer">DS</acronym> 
 +          <acronym role="Resource Record">RR</acronym> set.  Create a file
 +          containing these <acronym role="Resource Record">RR</acronym>s with
 +        </para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . &gt; root.ds</userinput></screen>
 +
 +        <para>These records use SHA-1 and SHA-256 respectively, and should
 +          look similar to the following example, where the longer is using
 +          SHA-256.</para>
 +
 +        <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
 +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
 +
 +	<para>The SHA-256 <acronym>RR</acronym> can now be compared to the
 +	  digest in <ulink url="https://data.iana.org/root-anchors/root-anchors.xml">
 +	  https://data.iana.org/root-anchors/root-anchors.xml</ulink>.  To be
 +	  absolutely sure that the key has not been tampered with the data in
 +	  the <acronym>XML</acronym> file can be verified using the
 +	  <acronym>PGP</acronym> signature in <ulink
 +	  url="https://data.iana.org/root-anchors/root-anchors.asc">
 +	  https://data.iana.org/root-anchors/root-anchors.asc</ulink>.</para>
 +	    
 +	<para>Next, the key must be formatted properly.  This differs a
 +	  little between <acronym>BIND</acronym> versions 9.6.2 and 9.7 and
 +	  later.  In version 9.7 support was added to automatically track
 +	  changes to the key and update it as necessary.  This is done using
 +	  <literal>managed-keys</literal> as seen in the example below.
 +	  When using the older version, the key is added using a
 +	  <literal>trusted-keys</literal> statement and updates must be done
 +	  manually.  For <acronym>BIND</acronym> 9.6.2 the format should look
 +	  like:</para>
 +
 +	<programlisting>trusted-keys {
 +	"." 257 3 8
 +	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 +	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 +	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 +	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 +	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 +	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
 +	QxA+Uk1ihz0=";
 +};</programlisting>
 +
 +	<para>For 9.7 the format will instead be:</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>The root key can now be added to <filename>named.conf</filename>
 +	  either directly or by including a file containing the key.  After
 +	  these steps, configure <acronym>BIND</acronym> to do
 +	  <acronym>DNSSEC</acronym> validation on queries by editing
 +	  <filename>named.conf</filename> and adding the following to the
 +	  <literal>options</literal> directive:</para>
 +
 +	  <programlisting>dnssec-enable yes;
 +dnssec-validation yes;</programlisting>
 +
 +	<para>To verify that it is actually working use
 +	  <application>dig</application> to make a query for a signed zone
 +	  using the resolver just configured.  A successful reply will contain
 +	  the <literal>AD</literal> flag to indicate the data was
 +	  authenticated.  Running a query such as</para>
 +
 +	<screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
 +
 +	<para>should return the <acronym>DS</acronym> <acronym>RR</acronym>
 +	  for the <literal>.se</literal> zone.  In the
 +	  <literal>flags:</literal> section the <literal>AD</literal> flag
 +	  should be set, as seen in:</para>
 +
 +	<programlisting>...
 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 +...</programlisting>
 +
 +	<para>The resolver is now capable of authenticating
 +	  <acronym>DNS</acronym> queries.</para>
 +      </sect3>
 +
 +      <sect3 id="dns-dnssec-auth">
 +        <title>Authoritative <acronym>DNS</acronym> server configuration</title>
 +
 +	<para>In order to get an authoritative name server to serve a
 +	  <acronym>DNSSEC</acronym> signed zone a little more work is
 +	  required.  A zone is signed using cryptographic keys which must be
 +	  generated.  It is possible to use only one key for this. The 
 +	  preferred method however is to have a strong well-protected Key Signing Key
 +	  (<acronym role="Key Signing Key">KSK</acronym>) that is not rotated
 +	  very often and a Zone Signing Key
 +	  (<acronym role="Zone Signing Key">ZSK</acronym>) that is rotated more
 +	  frequently.  Information on recommended operational practices can be
 +	  found in <ulink url="http://tools.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational 
 +	  Practices</ulink>.  Practices regarding the root zone can be found 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> and
 +	  <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>. The
 +          <acronym role="Key Signing Key">KSK</acronym> is used to build a chain
 +          of authority to the data in need of validation and as such is also
 +          called a Secure Entry Point
 +          (<acronym role="Secure Entry Point">SEP</acronym>) key.  A message
 +          digest of this key, called a Delegation Signer
 +          (<acronym role="Delegation Signer">DS</acronym>) record, must be
 +          published in the parent zone to establish the trust chain.  How
 +          this is accomplished depends on the parent zone owner.  The
 +          <acronym role="Zone Signing Key">ZSK</acronym> is used
 +          to sign the zone, and only needs to be published there.</para>
 +
 +        <para>To enable <acronym>DNSSEC</acronym> for the <hostid
 +          role="domainname">example.com</hostid> zone depicted in previous
 +          examples, the first step is to use
 +          <application>dnssec-keygen</application> to generate the
 +          <acronym>KSK</acronym> and <acronym>ZSK</acronym> key pair.  This
 +          key pair can utilize different cryptographic algorithms.  It is
 +          recommended to use RSA/SHA256 for the keys and 2048 bits key length
 +          should be enough. To generate the <acronym>KSK</acronym> for
 +          <hostid role="domainname">example.com</hostid>, run</para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +
 +        <para>and to generate the <acronym>ZSK</acronym>, run</para>
 +
 +        <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
 +
 +        <para><application>dnssec-keygen</application> outputs two files, the
 +          public and the private keys in files named similar to
 +          <filename>Kexample.com.+005+nnnnn.key</filename> (public) and
 +          <filename>Kexample.com.+005+nnnnn.private</filename> (private). The
 +          <literal>nnnnn</literal> part of the file name is a five digit key ID.
 +          Keep track of which key ID belongs to which key.  This is especially
 +          important when having more than one key in a zone.  It is also
 +          possible to rename the keys.  For each <acronym>KSK</acronym> file
 +          do:</para>
 +
 +        <screen>&prompt.user; <userinput>mv Kexample.com+005+nnnnn.key Kexample.com+005+nnnnn.KSK.key</userinput>
 +          &prompt.user; <userinput>mv Kexample.com+005+nnnnn.private Kexample.com+005+nnnnn.KSK.private</userinput></screen>
 +
 +        <para>For the <acronym>ZSK</acronym> files, substitute
 +          <literal>KSK</literal> for <literal>ZSK</literal> as necessary.  The
 +          files can now be included in the zone file, using the
 +          <literal>$include</literal> statement. It should look something like
 +          this:</para>
 +
 +	<programlisting>$include Kexample.com.+005+nnnnn.KSK.key    ; KSK
 +$include Kexample.com.+005+nnnnn.ZSK.key    ; ZSK</programlisting>
 +
 +	<para>Finally, sign the zone and tell <acronym>BIND</acronym> to use
 +	  the signed zone file.  To sign a zone
 +	  <application>dnssec-signzone</application> is used.  The command to
 +	  sign the zone <hostid role="domainname">example.com</hostid>, located in
 +	  <filename>example.com.db</filename> would look similar to</para>
 +
 +	<screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com+005+nnnnn.KSK example.com.db Kexample.com+005+nnnnn.ZSK.key</userinput></screen>
 +
 +	<para>The key supplied to the <option>-k</option> argument is the
 +	  <acronym>KSK</acronym> and the other key file is the
 +	  <acronym>ZSK</acronym> that should be used in the signing.  It is
 +	  possible to supply more than one <acronym>KSK</acronym> and
 +	  <acronym>ZSK</acronym>, which will result in the zone being signed
 +	  with all supplied keys.  This can be needed to supply zone data
 +	  signed using more than one algorithm.  The output of
 +	  <application>dnssec-signzone</application> is a zone file with all
 +	  <acronym>RR</acronym>s signed.  This output will end up in a file with
 +	  the extension <literal>.signed</literal>, such as
 +	  <filename>example.com.db.signed</filename>.  The
 +	  <acronym role="Delegation Signer">DS</acronym> records will also be
 +	  written to a separate file <filename>dsset-example.com</filename>.
 +	  To use this signed zone just modify the zone directive in
 +	  <filename>named.conf</filename> to use
 +	  <filename>example.com.db.signed</filename>.  By default, the
 +	  signatures are only valid 30 days, meaning that the zone needs to
 +	  be resigned in about 15 days to be sure that resolvers are not
 +	  caching records with stale signatures.  It is possible to make a
 +	  script and a cron job to do this.  See relevant manuals for details.
 +	</para>
 +
 +	<para>Be sure to keep private keys confidential, as with all
 +	  cryptographic keys.  When changing a key it is best to include the
 +	  new key into the zone, while still signing with
 +	  the old one, and then move over to using the new key to sign.  After
 +	  these steps are done the old key can be removed from the zone.
 +	  Failure to do this might render the <acronym>DNS</acronym> data
 +	  unavailable for a time, until the new key has propagated through the
 +	  <acronym>DNS</acronym> hierarchy.  For more information on key
 +	  rollovers and other <acronym>DNSSEC</acronym> operational issues, see
 +	  <ulink url="http://www.ietf.org/rfc/rfc4641.txt">
 +	  <acronym>RFC</acronym> 4641: <acronym>DNSSEC</acronym> Operational
 +	  practices</ulink>.</para>
 +      </sect3>
 +
 +      <sect3>
 +        <title>Automation using <acronym>BIND</acronym> 9.7 or later</title>
 +        <para>Beginning with <acronym>BIND</acronym> version 9.7 a new feature
 +          called <emphasis>Smart Signing</emphasis> was introduced.  This
 +          feature aims to make the key management and signing process simpler by
 +          automating parts of the task.  By putting the keys into a directory
 +          called a <emphasis>key repository</emphasis>, and using the new option
 +          <literal>auto-dnssec</literal>, it is possible to create a dynamic zone
 +          which will be resigned as needed.  To update this zone use
 +          <application>nsupdate</application> with the new option
 +          <option>-l</option>. <application>rndc</application> has
 +          also grown the ability to sign zones with keys in the key repository,
 +          using the option <option>sign</option>.  To tell
 +          <acronym>BIND</acronym> to use this automatic signing and zone
 +          updating for <hostid role="domainname">example.com</hostid>, add the
 +          following to <filename>named.conf</filename>:</para>
 +
 +	<programlisting>zone example.com {
 +	type master;
 +	key-directory "/etc/named/keys";
 +	update-policy local;
 +	auto-dnssec maintain;
 +	file "/etc/named/dynamic/example.com.zone";
 +};</programlisting> 
 +
 +	<para>After making these changes, generate keys for the zone as
 +	  explained in <xref linkend="dns-dnssec-auth">, put those keys
 +	  in the key repository given as the argument to the
 +	  <literal>key-directory</literal> in the zone configuration and the
 +	  zone will be signed automatically.  Updates to a zone configured
 +	  this way must be done using
 +	  <application>nsupdate</application>, which will take care of
 +	  re-signing the zone with the new data added.  For further details,
 +	  see <xref linkend="dns-read"> and the <acronym>BIND</acronym>
 +	  documentation.</para>
 +	</sect3>
 +
 +    </sect2>
 +
 +    <sect2>
        <title>Security</title>
  
        <para>Although BIND is the most common implementation of DNS,
 @@ -3897,11 +4231,12 @@
        </tip>
      </sect2>
  
 -    <sect2>
 +    <sect2 id="dns-read">
        <title>Further Reading</title>
  
        <para>BIND/<application>named</application> manual pages:
 -      &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>
 @@ -3922,6 +4257,17 @@
  	</listitem>
  
  	<listitem>
 +	  <para><ulink url="http://www.root-dnssec.org/documentation/"> Root
 +	      <acronym>DNSSEC</acronym></ulink></para>
 +	</listitem>
 +
 +	<listitem>
 +	  <para><ulink 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 Facilities</ulink></para>
 @@ -3932,6 +4278,38 @@
  	      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">RFC 5011
 +	      - Automated Updates of DNS Security (<acronym>DNSSEC</acronym>
 +	      Trust Anchors</ulink></para>
 +	</listitem>
 +
        </itemizedlist>
      </sect2>
    </sect1>
 Index: share/sgml/man-refs.ent
 ===================================================================
 RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v
 retrieving revision 1.511
 diff -u -d -r1.511 man-refs.ent
 --- share/sgml/man-refs.ent	11 Feb 2011 16:15:44 -0000	1.511
 +++ share/sgml/man-refs.ent	24 May 2011 19:55:12 -0000
 @@ -4257,6 +4257,8 @@
  <!ENTITY man.diskpart.8 "<citerefentry/<refentrytitle/diskpart/<manvolnum/8//">
  <!ENTITY man.dm.8 "<citerefentry/<refentrytitle/dm/<manvolnum/8//">
  <!ENTITY man.dmesg.8 "<citerefentry/<refentrytitle/dmesg/<manvolnum/8//">
 +<!ENTITY man.dnssec-keygen.8 "<citerefentry/<refentrytitle/dnssec-keygen<manvolnum/8//">
 +<!ENTITY man.dnssec-signzone.8 "<citerefentry/<refentrytitle/dnssec-signzone<manvolnum/8//">
  <!ENTITY man.dump.8 "<citerefentry/<refentrytitle/dump/<manvolnum/8//">
  <!ENTITY man.dumpfs.8 "<citerefentry/<refentrytitle/dumpfs/<manvolnum/8//">
  <!ENTITY man.dumpon.8 "<citerefentry/<refentrytitle/dumpon/<manvolnum/8//">
 
 --------------000703050907060405020802--

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: docs/157245: commit references a PR
Date: Wed, 25 May 2011 14:18:28 +0000 (UTC)

 bcr         2011-05-25 14:18:20 UTC
 
   FreeBSD doc repository
 
   Modified files:
     share/sgml           man-refs.ent 
     en_US.ISO8859-1/books/handbook/network-servers chapter.sgml 
   Log:
   Please welcome a new section about DNSSEC to the handbook.
   A detailed introduction to the problem is given, as well as examples
   for setting up DNSSEC with BIND and further readings are included.
   
   A big thank you to Niclas Zeising for the writeup and others who provided
   feedback and corrections/additions.
   
   PR:             docs/157245
   Submitted by:   Niclas Zeising (niclas dot zeising at gmail dot com)
   Additions by:   Benjamin Kaduk, Warren Block, dougb@
   
   Revision  Changes    Path
   1.132     +392 -30   doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
   1.512     +2 -0      doc/share/sgml/man-refs.ent
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: bcr 
State-Changed-When: Wed May 25 14:30:20 UTC 2011 
State-Changed-Why:  
Patch committed. Thanks to all who were involved in this. 
Good teamwork between contributors and committers! PR closed.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=157245 
>Unformatted:
