KASP Inactive/Retired timestamps

[Matthijs Mekking]

Hi Gregory,

Thanks for trying out out the new KASP. Let me try to answer your
questions below.

On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote:
> After the fantastic ISC DNSSEC webinar series last month, I began
> using KASP for my DNSSEC signed zones.  I have noticed an odd
> behavior with regards to the files BIND keeps in keys/ (K*.key,
> K*.private, and K*.state).  For inactive/retired keys, every BIND
> restart updates the dates in those files (see below).  This raises
> two questions:
> 
> 1. Should the time a key becomes inactive or retired be a fixed point
> in time rather than changing to the last time BIND restarted for
> every restart?

Named now takes care of the rollover, taking over the job of fiddling
with dnssec-keymgr. That means that named will set the key times.

Note that a key time is an indication of an event happening: if the
underlying state machine thinks it is not yet safe to do so, the event
will happen at a later point in time.

In other words, the keymgr embedded in named is making decisions on
rollover actions based on this state machine, not the key times.  The
key times do help the user to see when key rollovers will happen.

In principle these times are fixed, but changes in key files (a key gets
published, a change in key lifetime, ...)  will trigger updating the key
times.


> 2. When, if ever, is it safe to remove the files from the keys
> directory for inactive/retired keys (i.e., is there a state after
> Inactive or Retired)?

There is a Deleted time as well, at this point the key and corresponding
signatures should no longer occur in the zone.  When looking at the key
state files: if all states are in "hidden" it is safe to prune the files.

> An example set of changes is shown in the pruned diff below.  Note
> that for this particular key, the state file shows the following
> states:

Thanks for showing this example. This is a minor bug. What happens is
that the key file matches your dnssec-policy but most likely another
active key also matches. Any excess keys are retired immediately (even
if this key was already retired previously).


Best regards,

Matthijs


> DNSKEYState: hidden ZRRSIGState: hidden GoalState: hidden
> 
> --- Kgshapiro.net.+008+05640.key        18 May 2020 02:06:14 -0000
> 1.9 +++ Kgshapiro.net.+008+05640.key        19 May 2020 23:53:06
> -0000 -; Inactive: 20200518020420 (Tue May 18 02:04:20 2020) +;
> Inactive: 20200519230430 (Tue May 19 23:04:30 2020)
> 
> --- Kgshapiro.net.+008+05640.private    18 May 2020 02:06:14 -0000
> 1.9 +++ Kgshapiro.net.+008+05640.private    19 May 2020 23:53:06
> -0000 -Inactive: 20200518020420 +Inactive: 20200519230430
> 
> --- Kgshapiro.net.+008+05640.state      18 May 2020 02:06:14 -0000
> 1.8 +++ Kgshapiro.net.+008+05640.state      19 May 2020 23:53:06
> -0000 -Retired: 20200518020420 (Tue May 18 02:04:20 2020) +Retired:
> 20200519230430 (Tue May 19 23:04:30 2020)
> 
> Thanks! _______________________________________________ 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 at lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200520/cc5b0dea/attachment.bin>