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 23:30:15 UTC 2011
The following reply was made to PR docs/157245; it has been noted by GNATS.
From: Niclas Zeising <niclas.zeising at gmail.com>
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: 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 . > 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 . > 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--
More information about the freebsd-doc
mailing list