DNSSEC questions
Alessandro Vesely
vesely at tana.it
Thu Oct 28 11:25:51 UTC 2021
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
--
More information about the bind-users
mailing list