DNSSEC questions

[Alessandro Vesely]

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
--