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.

The syntax for "managed-keys" is identical to that for "trusted-keys".

However, whereas a trusted key is trusted permanently until it is removed

from named.conf, a managed key is only trusted for as long as it takes to

initialize RFC5011 key maintenance.

When named loads for the first time with a managed key configured, it

will fetch the DNSKEY RRset directly from the zone apex and check its

signature against the key specified in the "managed-keys" statement.

If it is validly signed, then the DNSKEY RRset is used as the basis for a

new managed keys database.

From that point on, when named loads, it will see the "managed-keys"

statement, check to make sure RFC5011 key maintenance has already been

initialized for the specified zone, and if so, it will simply move 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.