95 lines
4.7 KiB
XML
95 lines
4.7 KiB
XML
<!--
|
|
- 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 takes note
|
|
of the stand-by KSKs in the zone's DNSKEY RRset, and stores them
|
|
for future reference. The resolver rechecks the zone
|
|
periodically; after 30 days, if the new key is still there,
|
|
the key is accepted by the resolver as a valid trust
|
|
anchor for the zone. Anytime 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 exists with a publication
|
|
date in the past, but an activation date which is unset or in
|
|
the future, <command>dnssec-signzone -S</command> includes the DNSKEY
|
|
record in the zone but does 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, use the command
|
|
<command>dnssec-revoke</command>. This adds the
|
|
REVOKED bit to the key flags and regenerates 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 is never again
|
|
accepted as a valid trust anchor by the resolver. However,
|
|
validation can proceed using the new active key, which was
|
|
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, the two key IDs will collide, causing several
|
|
problems. To prevent this,
|
|
<command>dnssec-keygen</command> does not generate a new key if
|
|
another key which may collide is present. This checking
|
|
only occurs if the new keys are written to the same directory
|
|
that holds all other keys in use for that zone.</para>
|
|
<para>Older versions of BIND 9 did not have this protection.
|
|
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>
|