From 3b9b6d0b8e7f798023c9d109c490449d528fde80 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:59:48 +0200 Subject: Adding upstream version 1:9.18.19. Signed-off-by: Daniel Baumann --- doc/arm/managed-keys.inc.rst | 92 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 doc/arm/managed-keys.inc.rst (limited to 'doc/arm/managed-keys.inc.rst') diff --git a/doc/arm/managed-keys.inc.rst b/doc/arm/managed-keys.inc.rst new file mode 100644 index 0000000..a8eb4c7 --- /dev/null +++ b/doc/arm/managed-keys.inc.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 :iscman:`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 :any:`trust-anchors` statement and +the ``initial-key`` keyword. Information about this can be found in +the :any:`trust-anchors` statement description. + +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 :iscman:`dnssec-keygen` and :iscman:`dnssec-signzone`. If a key +exists with a publication date in the past, but an activation date which is +unset or in the future, :option:`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 :iscman:`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, +:iscman:`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