1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
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>
|
