2eeb74d1cf5355dd98f6d507a10086e16bb08c4bTinderbox User

83a28ca274521e15086fc39febde507bcc4e145eMark Andrews<section xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="rfc5011.support"><info><title>Dynamic Trust Anchor Management</title></info>

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt <para>

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt BIND is able to maintain DNSSEC trust anchors using RFC 5011 key

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt management. This feature allows <command>named</command> to keep track

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt of changes to critical DNSSEC keys without any need for the operator to

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt make changes to configuration files.

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt </para>

17b7c609028e5acb847b6f78833d008f820daa5dEvan Hunt

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt <section><info><title>Validating Resolver</title></info>

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <!-- TODO: command tag is overloaded for configuration and executables -->

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>To configure a validating resolver to use RFC 5011 to

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews maintain a trust anchor, configure the trust anchor using a

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <command>managed-keys</command> statement. Information about

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews this can be found in

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt <xref linkend="managed-keys"/>.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <!-- TODO: managed-keys examples

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt </section>

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt <section><info><title>Authoritative Server</title></info>

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>To set up an authoritative zone for RFC 5011 trust anchor

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt maintenance, generate two (or more) key signing keys (KSKs) for

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt the zone. Sign the zone with one of them; this is the "active"

edad003e630cf9a25db88d95247d10eb96117d66Jeremy C. Reed KSK. All KSKs which do not sign the zone are "stand-by"

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt keys.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>Any validating resolver which is configured to use the

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt active KSK as an RFC 5011-managed trust anchor will take note

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt of the stand-by KSKs in the zone's DNSKEY RRset, and store them

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt for future reference. The resolver will recheck the zone

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt periodically, and after 30 days, if the new key is still there,

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt then the key will be accepted by the resolver as a valid trust

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt anchor for the zone. Any time after this 30-day acceptance

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt timer has completed, the active KSK can be revoked, and the

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt zone can be "rolled over" to the newly accepted key.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>The easiest way to place a stand-by key in a zone is to

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews use the "smart signing" features of

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews <command>dnssec-keygen</command> and

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <command>dnssec-signzone</command>. If a key with a publication

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt date in the past, but an activation date which is unset or in

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews the future, "

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <command>dnssec-signzone -S</command>" will include the DNSKEY

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt record in the zone, but will not sign with it:</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <screen>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt$ <userinput>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</userinput>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt$ <userinput>dnssec-signzone -S -K keys example.net</userinput>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt</screen>

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews <para>To revoke a key, the new command

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <command>dnssec-revoke</command> has been added. This adds the

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews REVOKED bit to the key flags and re-generates the

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews <filename>K*.key</filename> and

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <filename>K*.private</filename> files.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>After revoking the active key, the zone must be signed

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt with both the revoked KSK and the new active KSK. (Smart

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt signing takes care of this automatically.)</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>Once a key has been revoked and used to sign the DNSKEY

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt RRset in which it appears, that key will never again be

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt accepted as a valid trust anchor by the resolver. However,

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt validation can proceed using the new active key (which had been

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt accepted by the resolver when it was a stand-by key).</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>See RFC 5011 for more details on key rollover

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt scenarios.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>When a key has been revoked, its key ID changes,

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt increasing by 128, and wrapping around at 65535. So, for

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt example, the key "<filename>Kexample.com.+005+10000</filename>" becomes

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt "<filename>Kexample.com.+005+10128</filename>".</para>

edad003e630cf9a25db88d95247d10eb96117d66Jeremy C. Reed <para>If two keys have IDs exactly 128 apart, and one is

edad003e630cf9a25db88d95247d10eb96117d66Jeremy C. Reed revoked, then the two key IDs will collide, causing several

30eec077db2bdcb6f2a0dc388a3cdde2ede75ec1Mark Andrews problems. To prevent this,

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <command>dnssec-keygen</command> will not generate a new key if

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt another key is present which may collide. This checking will

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt only occur if the new keys are written to the same directory

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt which holds all other keys in use for that zone.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>Older versions of BIND 9 did not have this precaution.

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt Exercise caution if using key revocation on keys that were

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt generated by previous releases, or if using keys stored in

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt multiple directories or on multiple machines.</para>

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt <para>It is expected that a future release of BIND 9 will

0b24b2d3c423560a0a4cd9a4476b9a2dcafb7ea3Evan Hunt address this problem in a different way, by storing revoked

edad003e630cf9a25db88d95247d10eb96117d66Jeremy C. Reed keys with their original unrevoked key IDs.</para>

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt </section>

14a656f94b1fd0ababd84a772228dfa52276ba15Evan Hunt</section>