diff options
Diffstat (limited to 'doc/arm/managed-keys.xml')
| -rw-r--r-- | doc/arm/managed-keys.xml | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/doc/arm/managed-keys.xml b/doc/arm/managed-keys.xml new file mode 100644 index 0000000..ba45a6c --- /dev/null +++ b/doc/arm/managed-keys.xml @@ -0,0 +1,95 @@ +<!-- + - Copyright (C) Internet Systems Consortium, Inc. ("ISC") + - + - This Source Code Form is subject to the terms of the Mozilla Public + - License, v. 2.0. If a copy of the MPL was not distributed with this + - file, You can obtain one at http://mozilla.org/MPL/2.0/. + - + - See the COPYRIGHT file distributed with this work for additional + - information regarding copyright ownership. +--> + +<!-- Converted by db4-upgrade version 1.0 --> +<section xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="rfc5011.support"><info><title>Dynamic Trust Anchor Management</title></info> + + <para> + BIND is able to maintain DNSSEC trust anchors using RFC 5011 key + management. This feature allows <command>named</command> to keep track + of changes to critical DNSSEC keys without any need for the operator to + make changes to configuration files. + </para> + + <section><info><title>Validating Resolver</title></info> + + <!-- TODO: command tag is overloaded for configuration and executables --> + <para>To configure a validating resolver to use RFC 5011 to + maintain a trust anchor, configure the trust anchor using a + <command>managed-keys</command> statement. Information about + this can be found in + <xref linkend="managed-keys"/>.</para> + <!-- TODO: managed-keys examples +also in DNSSEC section above here in ARM --> + </section> + <section><info><title>Authoritative Server</title></info> + + <para>To set up an authoritative zone for RFC 5011 trust anchor + maintenance, generate two (or more) key signing keys (KSKs) for + the zone. Sign the zone with one of them; this is the "active" + KSK. All KSKs which do not sign the zone are "stand-by" + keys.</para> + <para>Any validating resolver which is configured to use the + active KSK as an RFC 5011-managed trust anchor will take note + of the stand-by KSKs in the zone's DNSKEY RRset, and store them + for future reference. The resolver will recheck the zone + periodically, and after 30 days, if the new key is still there, + then the key will be accepted by the resolver as a valid trust + anchor for the zone. Any time after this 30-day acceptance + timer has completed, the active KSK can be revoked, and the + zone can be "rolled over" to the newly accepted key.</para> + <para>The easiest way to place a stand-by key in a zone is to + use the "smart signing" features of + <command>dnssec-keygen</command> and + <command>dnssec-signzone</command>. If a key with a publication + date in the past, but an activation date which is unset or in + the future, " + <command>dnssec-signzone -S</command>" will include the DNSKEY + record in the zone, but will not sign with it:</para> + <screen> +$ <userinput>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</userinput> +$ <userinput>dnssec-signzone -S -K keys example.net</userinput> +</screen> + <para>To revoke a key, the new command + <command>dnssec-revoke</command> has been added. This adds the + REVOKED bit to the key flags and re-generates the + <filename>K*.key</filename> and + <filename>K*.private</filename> files.</para> + <para>After revoking the active key, the zone must be signed + with both the revoked KSK and the new active KSK. (Smart + signing takes care of this automatically.)</para> + <para>Once a key has been revoked and used to sign the DNSKEY + RRset in which it appears, that key will never again be + accepted as a valid trust anchor by the resolver. However, + validation can proceed using the new active key (which had been + accepted by the resolver when it was a stand-by key).</para> + <para>See RFC 5011 for more details on key rollover + scenarios.</para> + <para>When a key has been revoked, its key ID changes, + increasing by 128, and wrapping around at 65535. So, for + example, the key "<filename>Kexample.com.+005+10000</filename>" becomes + "<filename>Kexample.com.+005+10128</filename>".</para> + <para>If two keys have IDs exactly 128 apart, and one is + revoked, then the two key IDs will collide, causing several + problems. To prevent this, + <command>dnssec-keygen</command> will not generate a new key if + another key is present which may collide. This checking will + only occur if the new keys are written to the same directory + which holds all other keys in use for that zone.</para> + <para>Older versions of BIND 9 did not have this precaution. + Exercise caution if using key revocation on keys that were + generated by previous releases, or if using keys stored in + multiple directories or on multiple machines.</para> + <para>It is expected that a future release of BIND 9 will + address this problem in a different way, by storing revoked + keys with their original unrevoked key IDs.</para> + </section> +</section> |