Attachment 115483 Details for Bug 157245 – network-servers.chapter.sgml.diff

[patch] network-servers.chapter.sgml.diff

network-servers.chapter.sgml.diff (text/plain), 17.85 KB, created by Niclas Zeising on 2011-05-22 10:40:08 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Niclas Zeising

Created: 2011-05-22 10:40:08 UTC

Size: 17.85 KB

patch

obsolete

>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>

Actions: View | Diff

Attachments on bug 157245: 115483 | 115484 | 115485 | 115486 | 115487 | 115488