diff options
Diffstat (limited to 'contrib/bind9/doc/arm/managed-keys.xml')
| -rw-r--r-- | contrib/bind9/doc/arm/managed-keys.xml | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/contrib/bind9/doc/arm/managed-keys.xml b/contrib/bind9/doc/arm/managed-keys.xml deleted file mode 100644 index 51949487fbb4..000000000000 --- a/contrib/bind9/doc/arm/managed-keys.xml +++ /dev/null @@ -1,100 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- - - Copyright (C) 2010 Internet Systems Consortium, Inc. ("ISC") - - - - Permission to use, copy, modify, and/or distribute this software for any - - purpose with or without fee is hereby granted, provided that the above - - copyright notice and this permission notice appear in all copies. - - - - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - - PERFORMANCE OF THIS SOFTWARE. ---> - -<!-- $Id: managed-keys.xml,v 1.3 2010/02/03 23:49:07 tbox Exp $ --> - -<sect1 id="rfc5011.support"> - <title>Dynamic Trust Anchor Management</title> - <para>BIND 9.7.0 introduces support for RFC 5011, dynamic trust - anchor management. Using 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> - <sect2> - <title>Validating Resolver</title> - <!-- 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 --> - </sect2> - <sect2> - <title>Authoritative Server</title> - <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 KSK's 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 ID's exactly 128 apart, and one is - revoked, then the two key ID's 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 ID's.</para> - </sect2> -</sect1> |