83 lines
3.6 KiB
Plaintext
83 lines
3.6 KiB
Plaintext
BIND 9.7.0 introduces support for RFC 5011, dynamic trust anchor
|
|
management. Using this feature allows named to keep track of changes to
|
|
critical DNSSEC keys without any need for the operator to make changes to
|
|
configuration files.
|
|
|
|
As of 9.7.0a1, the syntax for using RFC5011 is expected to change, so
|
|
proper documentation has yet to be written. This file is intended to
|
|
provide enough information to get started.
|
|
|
|
AUTHORITATIVE SERVER
|
|
--------------------
|
|
|
|
To set up an authoritative zone for RFC5011 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.
|
|
|
|
Any validating resolver which is configured to use the active KSK as an
|
|
RFC5011-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.
|
|
|
|
At any time after this 30-day acceptance timer has expired, the active
|
|
KSK can be revoked and the zone can be "rolled over" to one of the
|
|
standby KSKs.
|
|
|
|
To revoke a key, the new command "dnssec-revoke" has been added. This adds
|
|
the REVOKED bit to the key flags and re-generates the K*.key and K*.private
|
|
files.
|
|
|
|
After revoking the active key, the zone must be signed with both the
|
|
revoked KSK and the new active KSK. 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).
|
|
|
|
See RFC 5011 for more details on key rollover scenarios.
|
|
|
|
VALIDATING RESOLVER
|
|
-------------------
|
|
|
|
NOTE: This is expected to change before 9.7.0 is final!
|
|
|
|
To configure a validating resolver to use RFC5011 to maintain a trust
|
|
anchor, configure the trust anchor using a "managed-keys" statement
|
|
instead of a "trusted-keys" statement.
|
|
|
|
A "managed-keys" statement contains a list of keys to be maintained,
|
|
with information on how they are to be initialized the first time. The
|
|
only initialization method supported in BIND 9.7.0 is "initial-key".
|
|
This means the "managed-keys" statement itself will contain a copy of
|
|
the initializing key. In future releases, keys may be initialized by
|
|
other methods, removing the need to incorporate a copy of an intializing
|
|
key in named.conf.
|
|
|
|
Example:
|
|
|
|
managed-keys {
|
|
sample.domain. initial-key 257 3 5 "BEAAAAPHMu ...";
|
|
};
|
|
|
|
At first glance this is very similar to a "trusted-keys" statement,
|
|
differing only in the presence of the second field, "initial-key".
|
|
However, whereas a trusted key is trusted permanently until it is
|
|
removed from named.conf, this key would only be trusted once, for
|
|
as long as it takes to initialize RFC5011 key maintenance.
|
|
|
|
The first time named runs with a managed key configured in named.conf,
|
|
it fetches the DNSKEY RRset directly from the zone apex, and validates
|
|
it using the key specified in the "managed-keys" statement, as above.
|
|
If the DNSKEY RRset is validly signed, then it is used as the basis for
|
|
a new managed keys database.
|
|
|
|
From that point on, whenever named loads, it sees the "managed-keys"
|
|
statement, checks to make sure RFC5011 key maintenance has already been
|
|
initialized for the specified zone, and if so, it simply moves on.
|
|
No action will be taken unless a key is *removed* from the "managed-keys"
|
|
statement--in which case that zone is removed from the managed keys
|
|
database as well, and RFC5011 key maintenance will no longer be used.
|