ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Merge branch '2890-update-documentation-with-respect-to-sig-validity-interval-and-update-v9_16' into 'v9_16'

Browse Source 
Update sig-validity-interval description

See merge request isc-projects/bind9!5379
This commit is contained in:
Mark Andrews
2021-09-03 03:45:01 +00:00
parent 9174cff949 ad411b1120
commit 0a3e398e0c
1 changed files with 16 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
doc/arm/reference.rst
View File

@@ -3414,15 +3414,22 @@ Tuning
This sets the base retry interval in milliseconds. The default is ``800``.
``sig-validity-interval``
This specifies the number of days into the future that DNSSEC signatures
that are automatically generated as a result of dynamic updates
(:ref:`dynamic_update`) will expire. There is an optional second
field which specifies how long before expiry the signatures are
regenerated. If not specified, the signatures are regenerated
at 1/4 of the base interval. The second field is specified in days if the
base interval is greater than 7 days; otherwise it is specified in
hours. The default base interval is ``30`` days, giving a re-signing
interval of 7 1/2 days. The maximum value is 10 years (3660 days).
this specifies the upper bound of the number of days that RRSIGs
generated by ``named`` are valid; the default is ``30`` days,
with a maximum of 3660 days (10 years). The optional second value
specifies the minimum bound on those RRSIGs and also determines
how long before expiry ``named`` starts regenerating those RRSIGs.
The default value for the lower bound is 1/4 of the upper bound;
it is expressed in days if the upper bound is greater than 7,
and hours if it is less than or equal to 7 days.
When new RRSIGs are generated, the length of time is randomly
chosen between these two limits, to spread out the re-signing
load. When RRSIGs are re-generated, the upper bound is used, with
a small amount of jitter added. New RRSIGs are generated by a
number of processes, including the processing of UPDATE requests
(ref:`dynamic_update`), the addition and removal of records via
in-line signing, and the initial signing of a zone.
The signature inception time is unconditionally set to one hour
before the current time, to allow for a limited amount of clock skew.