Adding upstream version 1:9.16.44.upstream/1%9.16.44

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 92 insertions, 0 deletions

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.