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

Niclas Zeising zeising at daemonic.se
Sun May 22 21:50:10 UTC 2011


The following reply was made to PR docs/157245; it has been noted by GNATS.

From: Niclas Zeising <zeising at daemonic.se>
To: bug-followup at FreeBSD.org, niclas.zeising at 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 . > 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 .
 +          > 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--



More information about the freebsd-doc mailing list