docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook
Benjamin Kaduk
kaduk at MIT.EDU
Sun May 22 18:41:57 UTC 2011
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.
>
> --- 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"
>
More information about the freebsd-doc
mailing list