Merge branch '3397-document-interaction-dnssec-update-config-options-v9_16' into 'v9_16'

[v9_16] Document where updates and DNSSEC records are stored

See merge request isc-projects/bind9!6464
This commit is contained in:
Matthijs Mekking 2022-06-21 14:49:58 +00:00
commit 7ebf6e5c59
2 changed files with 23 additions and 4 deletions

View file

@ -1557,6 +1557,10 @@ named_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
RETERR(configure_zone_ssutable(zoptions, mayberaw, zname));
}
/*
* Configure DNSSEC signing. These apply to primary zones or zones that
* use inline-signing (raw != NULL).
*/
if (ztype == dns_zone_primary || raw != NULL) {
const cfg_obj_t *validity, *resign;
bool allow = false, maint = false;

View file

@ -2062,6 +2062,9 @@ Boolean Options
This option may only be activated at the zone level; if configured
at the view or options level, it must be set to ``off``.
The DNSSEC records are written to the zone's filename set in ``file``,
unless ``inline-signing`` is enabled.
``dnssec-enable``
This option is obsolete and has no effect.
@ -2407,6 +2410,8 @@ for details on how to specify IP address lists.
and inherited by zones, this could lead to some zones unintentionally
allowing updates.
Updates are written to the zone's filename that is set in ``file``.
``allow-update-forwarding``
When set in the ``zone`` statement for a secondary zone, this specifies which
hosts are allowed to submit Dynamic DNS updates and have them be
@ -4891,6 +4896,13 @@ Multiple key and signing policies can be configured. To attach a policy
to a zone, add a ``dnssec-policy`` option to the ``zone`` statement,
specifying the name of the policy that should be used.
By default, ``dnssec-policy`` assumes ``inline-signing``. This means that
a signed version of the zone is maintained separately and is written out to
a different file on disk (the zone's filename plus a ``.signed`` extension).
If the zone is dynamic because it is configured with an ``update-policy`` or
``allow-update``, the DNSSEC records are written to the filename set in the original zone's ``file``, unless ``inline-signing`` is explicitly set.
Key rollover timing is computed for each key according to the key
lifetime defined in the KASP. The lifetime may be modified by zone TTLs
and propagation delays, to prevent validation failures. When a key
@ -5769,10 +5781,12 @@ Zone Options
See the description of ``serial-update-method`` in :ref:`options`.
``inline-signing``
If ``yes``, this enables "bump in the wire" signing of a zone, where
an unsigned zone is transferred in or loaded from disk and a signed
If ``yes``, BIND 9 maintains a separate signed version of the zone.
An unsigned zone is transferred in or loaded from disk and the signed
version of the zone is served with, possibly, a different serial
number. This behavior is disabled by default.
number. The signed version of the zone is stored in a file that is
the zone's filename (set in ``file``) with a ``.signed`` extension.
This behavior is disabled by default.
``multi-master``
See the description of ``multi-master`` in :ref:`boolean_options`.
@ -5793,7 +5807,8 @@ Dynamic Update Policies
BIND 9 supports two methods of granting clients the right to
perform dynamic updates to a zone, configured by the ``allow-update``
or ``update-policy`` options.
or ``update-policy`` options. In both cases, BIND 9 writes the updates
to the zone's filename set in ``file``.
The ``allow-update`` clause is a simple access control list. Any client
that matches the ACL is granted permission to update any record in the