d29d9ab4614ff992b0e8de6e2b88d52b6f1f153erbowen

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

af33a4994ae2ff15bc67d19ff1a7feb906745bf8rbowen

3f08db06526d6901aa08c110b5bc7dde6bc39905nd <para>BIND 9.7.0 introduces support for RFC 5011, dynamic trust

0782f6cf216295b70cd608451422f5db560f2cf0kess anchor management. Using this feature allows

0782f6cf216295b70cd608451422f5db560f2cf0kess <command>named</command> to keep track of changes to critical

0782f6cf216295b70cd608451422f5db560f2cf0kess DNSSEC keys without any need for the operator to make changes to

3f08db06526d6901aa08c110b5bc7dde6bc39905nd configuration files.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <section><info><title>Validating Resolver</title></info>

0782f6cf216295b70cd608451422f5db560f2cf0kess

0782f6cf216295b70cd608451422f5db560f2cf0kess <!-- TODO: command tag is overloaded for configuration and executables -->

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>To configure a validating resolver to use RFC 5011 to

af84459fbf938e508fd10b01cb8d699c79083813takashi maintain a trust anchor, configure the trust anchor using a

4b3a8afbfcea8b265d179a122bf40dfedd1ce280takashi <command>managed-keys</command> statement. Information about

fac8c35bfb158112226ab43ddf84d59daca5dc30nd this can be found in

f086b4b402fa9a2fefc7dda85de2a3cc1cd0a654rjung <xref linkend="managed-keys"/>.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <!-- TODO: managed-keys examples

4b575a6b6704b516f22d65a3ad35696d7b9ba372rpluem </section>

4b575a6b6704b516f22d65a3ad35696d7b9ba372rpluem <section><info><title>Authoritative Server</title></info>

0782f6cf216295b70cd608451422f5db560f2cf0kess

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>To set up an authoritative zone for RFC 5011 trust anchor

0782f6cf216295b70cd608451422f5db560f2cf0kess maintenance, generate two (or more) key signing keys (KSKs) for

0782f6cf216295b70cd608451422f5db560f2cf0kess the zone. Sign the zone with one of them; this is the "active"

0782f6cf216295b70cd608451422f5db560f2cf0kess KSK. All KSKs which do not sign the zone are "stand-by"

0782f6cf216295b70cd608451422f5db560f2cf0kess keys.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>Any validating resolver which is configured to use the

0782f6cf216295b70cd608451422f5db560f2cf0kess active KSK as an RFC 5011-managed trust anchor will take note

0782f6cf216295b70cd608451422f5db560f2cf0kess of the stand-by KSKs in the zone's DNSKEY RRset, and store them

0782f6cf216295b70cd608451422f5db560f2cf0kess for future reference. The resolver will recheck the zone

0782f6cf216295b70cd608451422f5db560f2cf0kess periodically, and after 30 days, if the new key is still there,

0782f6cf216295b70cd608451422f5db560f2cf0kess then the key will be accepted by the resolver as a valid trust

0782f6cf216295b70cd608451422f5db560f2cf0kess anchor for the zone. Any time after this 30-day acceptance

0782f6cf216295b70cd608451422f5db560f2cf0kess timer has completed, the active KSK can be revoked, and the

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

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>The easiest way to place a stand-by key in a zone is to

0782f6cf216295b70cd608451422f5db560f2cf0kess use the "smart signing" features of

0782f6cf216295b70cd608451422f5db560f2cf0kess <command>dnssec-keygen</command> and

0782f6cf216295b70cd608451422f5db560f2cf0kess <command>dnssec-signzone</command>. If a key with a publication

0782f6cf216295b70cd608451422f5db560f2cf0kess date in the past, but an activation date which is unset or in

d1348237b33bc1755b9f1165eea52317465a7671nd the future, "

0782f6cf216295b70cd608451422f5db560f2cf0kess <command>dnssec-signzone -S</command>" will include the DNSKEY

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

0782f6cf216295b70cd608451422f5db560f2cf0kess <screen>

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

20189240503ef2c8f5dc6e2248b57faab4b23b5and$ <userinput>dnssec-signzone -S -K keys example.net</userinput>

20189240503ef2c8f5dc6e2248b57faab4b23b5and</screen>

20189240503ef2c8f5dc6e2248b57faab4b23b5and <para>To revoke a key, the new command

20189240503ef2c8f5dc6e2248b57faab4b23b5and <command>dnssec-revoke</command> has been added. This adds the

20189240503ef2c8f5dc6e2248b57faab4b23b5and REVOKED bit to the key flags and re-generates the

20189240503ef2c8f5dc6e2248b57faab4b23b5and <filename>K*.key</filename> and

20189240503ef2c8f5dc6e2248b57faab4b23b5and <filename>K*.private</filename> files.</para>

20189240503ef2c8f5dc6e2248b57faab4b23b5and <para>After revoking the active key, the zone must be signed

20189240503ef2c8f5dc6e2248b57faab4b23b5and with both the revoked KSK and the new active KSK. (Smart

0782f6cf216295b70cd608451422f5db560f2cf0kess signing takes care of this automatically.)</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>Once a key has been revoked and used to sign the DNSKEY

0782f6cf216295b70cd608451422f5db560f2cf0kess RRset in which it appears, that key will never again be

0782f6cf216295b70cd608451422f5db560f2cf0kess accepted as a valid trust anchor by the resolver. However,

0782f6cf216295b70cd608451422f5db560f2cf0kess validation can proceed using the new active key (which had been

0782f6cf216295b70cd608451422f5db560f2cf0kess accepted by the resolver when it was a stand-by key).</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>See RFC 5011 for more details on key rollover

0782f6cf216295b70cd608451422f5db560f2cf0kess scenarios.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>When a key has been revoked, its key ID changes,

0782f6cf216295b70cd608451422f5db560f2cf0kess increasing by 128, and wrapping around at 65535. So, for

0782f6cf216295b70cd608451422f5db560f2cf0kess example, the key "<filename>Kexample.com.+005+10000</filename>" becomes

0782f6cf216295b70cd608451422f5db560f2cf0kess "<filename>Kexample.com.+005+10128</filename>".</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>If two keys have IDs exactly 128 apart, and one is

0782f6cf216295b70cd608451422f5db560f2cf0kess revoked, then the two key IDs will collide, causing several

0782f6cf216295b70cd608451422f5db560f2cf0kess problems. To prevent this,

0782f6cf216295b70cd608451422f5db560f2cf0kess <command>dnssec-keygen</command> will not generate a new key if

0782f6cf216295b70cd608451422f5db560f2cf0kess another key is present which may collide. This checking will

0782f6cf216295b70cd608451422f5db560f2cf0kess only occur if the new keys are written to the same directory

0782f6cf216295b70cd608451422f5db560f2cf0kess which holds all other keys in use for that zone.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>Older versions of BIND 9 did not have this precaution.

0782f6cf216295b70cd608451422f5db560f2cf0kess Exercise caution if using key revocation on keys that were

0782f6cf216295b70cd608451422f5db560f2cf0kess generated by previous releases, or if using keys stored in

0782f6cf216295b70cd608451422f5db560f2cf0kess multiple directories or on multiple machines.</para>

0782f6cf216295b70cd608451422f5db560f2cf0kess <para>It is expected that a future release of BIND 9 will

d1348237b33bc1755b9f1165eea52317465a7671nd address this problem in a different way, by storing revoked

d1348237b33bc1755b9f1165eea52317465a7671nd keys with their original unrevoked key IDs.</para>

d1348237b33bc1755b9f1165eea52317465a7671nd </section>

0782f6cf216295b70cd608451422f5db560f2cf0kess</section>

0782f6cf216295b70cd608451422f5db560f2cf0kess