mirror of
https://gitlab.isc.org/isc-projects/bind9
synced 2025-08-22 01:59:26 +00:00
1322372a0c
We have had perpetual problem with Sphinx implicitly double-including files. To avoid that problem all files with name suffix .inc.rst are now ignored by Sphinx, and writter can conveniently include them without modifying conf.py for each and every file.
93 lines
3.8 KiB
ReStructuredText
93 lines
3.8 KiB
ReStructuredText
.. 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 ``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 :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.
|