[KASP] Key rollover

[Matthijs Mekking]

Hi Adrien,

I don't think it is fine yet. I see in your state file the following line:

 > DSState: hidden

This means the DS is not published according to BIND.

 > From my understanding, the second KSK should appear because I put the 
 > parameter "publish-safety 3d;" that is to say 3 days before the
 > expiration ("retired") of the key in use. is that right?

In addition to the DNSKEY TTL yes. The successor KSK should be 
pre-published the sum of dnskey-ttl, publish-safety, and 
zone-propagation-delay, prior to its retirement.

Best regards,

Matthijs

On 1/24/23 09:08, adrien sipasseuth wrote:
> Hello Matthijs,
> 
> Indeed I had not published the DS at my registar because I thought that 
> the second KSK would have appeared anyway at the time of the rollover.
> 
> I published the DS yesterday and I reported to BIND with the command you 
> gave me. I didn't find any error in the logs so everything must have 
> been fine!
> 
> here is the state file of the KSK in use :
> ; This is the state of key 46358, for ***********************.
> Algorithm: 13
> Length: 256
> Lifetime: 604800
> Predecessor: 28887
> KSK: yes
> ZSK: no
> Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
> Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
> Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
> Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
> Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
> DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
> PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
> DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
> DNSKEYState: omnipresent
> KRRSIGState: omnipresent
> DSState: hidden
> GoalState: omnipresent
> 
>  From my understanding, the second KSK should appear because I put the 
> parameter "publish-safety 3d;" that is to say 3 days before the 
> expiration ("retired") of the key in use. is that right?
> 
> that is to say tonight at 7pm, I will see tomorrow if this one appears.
> 
> regards, Adrien
> 
> 
> 
> Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking <matthijs at isc.org 
> <mailto:matthijs at isc.org>> a écrit :
> 
>     Hi Adrien,
> 
>     Without any logs or key **state** files, I can't really tell what is
>     going on.
> 
>     My only gut feeling is that you have never signaled BIND 9 that the DS
>     has been published. You can run 'rndc dnssec -checkds -key 12345
>     published example.com <http://example.com>' or set up
>     parental-agents to do it for you.
> 
>     Best regards,
> 
>     Matthijs
> 
>     On 1/17/23 09:38, adrien sipasseuth wrote:
>      > Hello,
>      >
>      > I put the management of DNSSEC with KASP, the zone is well
>     functional.
>      > (dig with "AD" flag etc)
>      >
>      > On the other hand, I can't see when the key rollover period for
>     my KSK
>      > is over (2 KSKs with a dig DNSKEY...)
>      >
>      > Without KASP, it was easy because I generated the second KSK key but
>      > with KASP, it is managed automatically.
>      >
>      > So, I have to adapt my scripts to check that there is :
>      >   - a used KSK key and a next KSK key
>      >   - Or only one KSK key used (if we are not in rollover phase)
>      >
>      > Except that with my current policy, I never see 2 KSKs via a "dig
>      > DNSKEY...".
>      > here is my policy :
>      >
>      > dnssec-policy "test" {
>      >      keys {
>      >          ksk lifetime P7D algorithm ecdsa256;
>      >          zsk lifetime P3D algorithm ecdsa256;
>      >      };
>      >      purge-keys 1d;
>      >      publish-safety 3d;
>      >      retire-safety 3d;
>      > };
>      >
>      > I see either my KSK in use or my next KSK (via "dig DNSKEY...") but
>      > never both at the same time.
>      >
>      > Is this a normal behavior or am I doing it wrong?
>      >
>      > Regards, Adrien
>      >
>     -- 
>     Visit https://lists.isc.org/mailman/listinfo/bind-users
>     <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/
>     <https://www.isc.org/contact/> for more information.
> 
> 
>     bind-users mailing list
>     bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
>     <https://lists.isc.org/mailman/listinfo/bind-users>
> 
>