On Thu 28/Oct/2021 09:34:42 +0200 Matthijs Mekking wrote:
On 27-10-2021 18:48, Alessandro Vesely wrote:
3. The server produces new .signed and .signed.jnl files every day, which
is inconvenient as the zone files directory is checked by tripwire. Is
that timing determined by the dnskey-ttl? Would it be okay to set it to
one month?
The zone is signed if a signature is about to expire. It is not determined
by dnskey-ttl. I would exclude these files from tripwire because they need
to written out anyway.
Then, why does it have to rewrite it every day, if the zone didn't change?
dnskey-ttl is the only one-day timing thing, except parent-ds-ttl.
It shouldn't. It should only rewrite if there are changes, for example due to
zone updates or due to resigning.
Nope. It logs these lines:
28-Oct-2021 04:50:23.230 notify: info: zone ext.tana.it/IN/external: sending
notifies (serial 2009110701)
28-Oct-2021 04:50:23.318 general: info: zone tana.it/IN/external (signed):
receive_secure_serial: unchanged
28-Oct-2021 04:50:23.374 notify: info: zone tana.it/IN/external (signed):
sending notifies (serial 2021102409)
28-Oct-2021 04:50:23.390 general: info: zone tana.it/IN/internal (signed):
receive_secure_serial: unchanged
(Note that the serial for both views is 2021101902. I don't know where th
logged numbers come from.)
And then Access/Modify/Change dates of .signed and .signed.jnl are 2021-10-28
04:50:47.000000000 +0200.
Furthermore, all the files in the keys directory, .key, .private, .state, are marked
12:50 today, which is a few minutes ago. All, except the ones for a zone still in
"auto-dnssec maintain" mode, and has no .state. The log says nothing about
this.
How can I investigate why? I run BIND 9.16.15-Debian (Stable Release)
<id:4469e3e>.
BTW, DS RR has a ttl of 10800 at the parent; should I copy that to
parent-ds-ttl in my policy definition?
Yes.
Done. However, I don't think I'll notice if they change it.
What for?
To make sure the key rollovers are timed correctly.
In addition, I took a closer look at your policy.
publish-safety P3W;
retire-safety P3W;
The publish-safety and retire-safety are intended to be small margins added to
rollover timings to give some extra time to cover unforeseen events. The
defaults are 1 hour. Maybe you have good reasons to set them to 3 weeks, but it
is remarkably long.
I thought if "unforeseen events" require manual intervention, I might be in a
hospital for a liver transplant, say, and need 3 weeks to be dismissed.
Best
Ale
--
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
