docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook

Niclas Zeising niclas.zeising at gmail.com
Sun May 22 09:40:09 UTC 2011


>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:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 22 09:40:08 UTC 2011
>Closed-Date:
>Last-Modified:
>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 at 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 .
+	  > 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 . > 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:
>Unformatted:



More information about the freebsd-doc mailing list