From 45d6379135504814ab723b57f0eb8be23393a51d Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 09:24:22 +0200 Subject: Adding upstream version 1:9.16.44. Signed-off-by: Daniel Baumann --- doc/arm/managed-keys.rst | 92 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 doc/arm/managed-keys.rst (limited to 'doc/arm/managed-keys.rst') diff --git a/doc/arm/managed-keys.rst b/doc/arm/managed-keys.rst new file mode 100644 index 0000000..d50dbdb --- /dev/null +++ b/doc/arm/managed-keys.rst @@ -0,0 +1,92 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. 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 https://mozilla.org/MPL/2.0/. +.. +.. See the COPYRIGHT file distributed with this work for additional +.. information regarding copyright ownership. + +.. _rfc5011.support: + +Dynamic Trust Anchor Management +------------------------------- + +BIND is able to maintain DNSSEC trust anchors using :rfc:`5011` key +management. 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. + +Validating Resolver +~~~~~~~~~~~~~~~~~~~ + +To configure a validating resolver to use :rfc:`5011` to maintain a trust +anchor, configure the trust anchor using a ``trust-anchors`` statement and +the ``initial-key`` keyword. Information about this can be found in +:ref:`trust-anchors`. + +Authoritative Server +~~~~~~~~~~~~~~~~~~~~ + +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. + +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. + +The easiest way to place a stand-by key in a zone is to use the "smart +signing" features of ``dnssec-keygen`` and ``dnssec-signzone``. If a key +exists with a publication date in the past, but an activation date which is +unset or in the future, ``dnssec-signzone -S`` includes the +DNSKEY record in the zone but does not sign with it: + +:: + + $ dnssec-keygen -K keys -f KSK -P now -A now+2y example.net + $ dnssec-signzone -S -K keys example.net + +To revoke a key, use the command ``dnssec-revoke``. This +adds the REVOKED bit to the key flags and regenerates 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. Smart signing takes care of this +automatically. + +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. + +See :rfc:`5011` for more details on key rollover scenarios. + +When a key has been revoked, its key ID changes, increasing by 128 and +wrapping around at 65535. So, for example, the key +"``Kexample.com.+005+10000``" becomes "``Kexample.com.+005+10128``". + +If two keys have IDs exactly 128 apart and one is revoked, the two +key IDs will collide, causing several problems. To prevent this, +``dnssec-keygen`` 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. + +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. + +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. -- cgit v1.2.3