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

Sun May 22 20:39:00 UTC 2011

On 22.5.2011 20:26, Benjamin Kaduk wrote:
> 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.

I believe the right person for the tech review is dougb@ (cc:ing him)

>>
>> --- 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 .
>> + > 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 . > 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 —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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-doc
>> To unsubscribe, send any mail to "freebsd-doc-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-doc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-doc
> To unsubscribe, send any mail to "freebsd-doc-unsubscribe at freebsd.org"


-- 
S pozdravom / Best regards
   Daniel Gerzo, FreeBSD committer