managed-keys.xml revision edad003e630cf9a25db88d95247d10eb96117d66
a7038d1a0513c8e804937ebc95fc9cb3a46c04f5Mark Andrews<?xml version="1.0" encoding="utf-8"?>
40f53fa8d9c6a4fc38c0014495e7a42b08f52481David Lawrence<!--
7c74e180c206e6ed99e8beb820da5f399d845c3eDavid Lawrence - Copyright (C) 2010 Internet Systems Consortium, Inc. ("ISC")
7c74e180c206e6ed99e8beb820da5f399d845c3eDavid Lawrence -
7c74e180c206e6ed99e8beb820da5f399d845c3eDavid Lawrence - Permission to use, copy, modify, and/or distribute this software for any
40f53fa8d9c6a4fc38c0014495e7a42b08f52481David Lawrence - purpose with or without fee is hereby granted, provided that the above
15a44745412679c30a6d022733925af70a38b715David Lawrence - copyright notice and this permission notice appear in all copies.
15a44745412679c30a6d022733925af70a38b715David Lawrence -
15a44745412679c30a6d022733925af70a38b715David Lawrence - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
15a44745412679c30a6d022733925af70a38b715David Lawrence - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
15a44745412679c30a6d022733925af70a38b715David Lawrence - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
15a44745412679c30a6d022733925af70a38b715David Lawrence - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
15a44745412679c30a6d022733925af70a38b715David Lawrence - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
15a44745412679c30a6d022733925af70a38b715David Lawrence - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
9c3531d72aeaad6c5f01efe6a1c82023e1379e4dDavid Lawrence - PERFORMANCE OF THIS SOFTWARE.
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence-->
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence<!-- $Id: managed-keys.xml,v 1.3 2010/02/03 23:49:07 tbox Exp $ -->
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence
7c74e180c206e6ed99e8beb820da5f399d845c3eDavid Lawrence<sect1 id="rfc5011.support">
21f1794606dce19928cf455029e173321f166380Mark Andrews <title>Dynamic Trust Anchor Management</title>
ea31416b4fcdf23732355a8002f93f29e3b3d2dbAndreas Gustafsson <para>BIND 9.7.0 introduces support for RFC 5011, dynamic trust
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence anchor management. Using this feature allows
64e41159a919b0711321fe688ca5da4f4d1b7d80Bob Halley <command>named</command> to keep track of changes to critical
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley DNSSEC keys without any need for the operator to make changes to
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley configuration files.</para>
be801b0fdbcf9b55b3a8cc6bf042ff6c86be6b11Mark Andrews <sect2>
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley <title>Validating Resolver</title>
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley <!-- TODO: command tag is overloaded for configuration and executables -->
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley <para>To configure a validating resolver to use RFC 5011 to
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff maintain a trust anchor, configure the trust anchor using a
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff <command>managed-keys</command> statement. Information about
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff this can be found in
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff <xref linkend="managed-keys" />.</para>
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff <!-- TODO: managed-keys examples
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graffalso in DNSSEC section above here in ARM -->
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff </sect2>
3d776d762914d1b675b4fd49728ce353ccf6f77eBrian Wellington <sect2>
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff <title>Authoritative Server</title>
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence <para>To set up an authoritative zone for RFC 5011 trust anchor
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence maintenance, generate two (or more) key signing keys (KSKs) for
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence the zone. Sign the zone with one of them; this is the "active"
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence KSK. All KSKs which do not sign the zone are "stand-by"
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence keys.</para>
91306d962f9d147d94b82fb14edb28f8d907cae7Andreas Gustafsson <para>Any validating resolver which is configured to use the
91306d962f9d147d94b82fb14edb28f8d907cae7Andreas Gustafsson active KSK as an RFC 5011-managed trust anchor will take note
91306d962f9d147d94b82fb14edb28f8d907cae7Andreas Gustafsson of the stand-by KSKs in the zone's DNSKEY RRset, and store them
91306d962f9d147d94b82fb14edb28f8d907cae7Andreas Gustafsson for future reference. The resolver will recheck the zone
91306d962f9d147d94b82fb14edb28f8d907cae7Andreas Gustafsson periodically, and after 30 days, if the new key is still there,
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence then the key will be accepted by the resolver as a valid trust
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence anchor for the zone. Any time after this 30-day acceptance
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence timer has completed, the active KSK can be revoked, and the
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence zone can be "rolled over" to the newly accepted key.</para>
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence <para>The easiest way to place a stand-by key in a zone is to
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence use the "smart signing" features of
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence <command>dnssec-keygen</command> and
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence <command>dnssec-signzone</command>. If a key with a publication
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence date in the past, but an activation date which is unset or in
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence the future, "
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <command>dnssec-signzone -S</command>" will include the DNSKEY
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley record in the zone, but will not sign with it:</para>
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <screen>
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff$ <userinput>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</userinput>
ce8c568e0d6106bb87069453505e09bc66754b40Andreas Gustafsson$ <userinput>dnssec-signzone -S -K keys example.net</userinput>
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley</screen>
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <para>To revoke a key, the new command
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <command>dnssec-revoke</command> has been added. This adds the
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley REVOKED bit to the key flags and re-generates the
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <filename>K*.key</filename> and
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <filename>K*.private</filename> files.</para>
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <para>After revoking the active key, the zone must be signed
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley with both the revoked KSK and the new active KSK. (Smart
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley signing takes care of this automatically.)</para>
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley <para>Once a key has been revoked and used to sign the DNSKEY
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley RRset in which it appears, that key will never again be
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley accepted as a valid trust anchor by the resolver. However,
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley validation can proceed using the new active key (which had been
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff accepted by the resolver when it was a stand-by key).</para>
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff <para>See RFC 5011 for more details on key rollover
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson scenarios.</para>
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson <para>When a key has been revoked, its key ID changes,
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson increasing by 128, and wrapping around at 65535. So, for
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson example, the key "<filename>Kexample.com.+005+10000</filename>" becomes
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson "<filename>Kexample.com.+005+10128</filename>".</para>
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson <para>If two keys have IDs exactly 128 apart, and one is
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence revoked, then the two key IDs will collide, causing several
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence problems. To prevent this,
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence <command>dnssec-keygen</command> will not generate a new key if
b587e1d83f007ce68a9ae93097c461d8eb7aa373Mark Andrews another key is present which may collide. This checking will
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence only occur if the new keys are written to the same directory
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence which holds all other keys in use for that zone.</para>
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence <para>Older versions of BIND 9 did not have this precaution.
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence Exercise caution if using key revocation on keys that were
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence generated by previous releases, or if using keys stored in
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence multiple directories or on multiple machines.</para>
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence <para>It is expected that a future release of BIND 9 will
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence address this problem in a different way, by storing revoked
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence keys with their original unrevoked key IDs.</para>
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence </sect2>
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence</sect1>
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence