<div dir="ltr"><div>Hello,</div><div><br></div><div>I don't why 
DSState: hidden, it's ok with some online check tools like :</div><div>- <a href="https://dnssec-analyzer.verisignlabs.com/">https://dnssec-analyzer.verisignlabs.com/</a></div><div>- <a href="https://zonemaster.net/fr/run-test">https://zonemaster.net/fr/run-test</a></div><div><br></div><div>my master is hidden, it can be related ? How i can debug this 
DSState: hidden ?<br></div><div><br></div><div>I found this command to check actual status : rndc dnssec -status **********</div><div>This is the output :</div><div>....<br></div><div>key: 46358 (ECDSAP256SHA256), KSK<br>  published:      yes - since Tue Jan 17 17:55:03 2023<br>  key signing:    yes - since Tue Jan 17 17:55:03 2023<br><br>  Next rollover scheduled on Tue Jan 24 17:55:03 2023<br>  - goal:           omnipresent<br>  - dnskey:         omnipresent<br>  - ds:             hidden<br>  - key rrsig:      omnipresent<br>...<br><br></div><div>Regards Adrien<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking <<a href="mailto:matthijs@isc.org">matthijs@isc.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Adrien,<br>
<br>
I don't think it is fine yet. I see in your state file the following line:<br>
<br>
 > DSState: hidden<br>
<br>
This means the DS is not published according to BIND.<br>
<br>
 > From my understanding, the second KSK should appear because I put the <br>
 > parameter "publish-safety 3d;" that is to say 3 days before the<br>
 > expiration ("retired") of the key in use. is that right?<br>
<br>
In addition to the DNSKEY TTL yes. The successor KSK should be <br>
pre-published the sum of dnskey-ttl, publish-safety, and <br>
zone-propagation-delay, prior to its retirement.<br>
<br>
Best regards,<br>
<br>
Matthijs<br>
<br>
On 1/24/23 09:08, adrien sipasseuth wrote:<br>
> Hello Matthijs,<br>
> <br>
> Indeed I had not published the DS at my registar because I thought that <br>
> the second KSK would have appeared anyway at the time of the rollover.<br>
> <br>
> I published the DS yesterday and I reported to BIND with the command you <br>
> gave me. I didn't find any error in the logs so everything must have <br>
> been fine!<br>
> <br>
> here is the state file of the KSK in use :<br>
> ; This is the state of key 46358, for ***********************.<br>
> Algorithm: 13<br>
> Length: 256<br>
> Lifetime: 604800<br>
> Predecessor: 28887<br>
> KSK: yes<br>
> ZSK: no<br>
> Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)<br>
> Published: 20230117165503 (Tue Jan 17 17:55:03 2023)<br>
> Active: 20230120180003 (Fri Jan 20 19:00:03 2023)<br>
> Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)<br>
> Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)<br>
> DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)<br>
> PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)<br>
> DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)<br>
> KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)<br>
> DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)<br>
> DNSKEYState: omnipresent<br>
> KRRSIGState: omnipresent<br>
> DSState: hidden<br>
> GoalState: omnipresent<br>
> <br>
>  From my understanding, the second KSK should appear because I put the <br>
> parameter "publish-safety 3d;" that is to say 3 days before the <br>
> expiration ("retired") of the key in use. is that right?<br>
> <br>
> that is to say tonight at 7pm, I will see tomorrow if this one appears.<br>
> <br>
> regards, Adrien<br>
> <br>
> <br>
> <br>
> Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking <<a href="mailto:matthijs@isc.org" target="_blank">matthijs@isc.org</a> <br>
> <mailto:<a href="mailto:matthijs@isc.org" target="_blank">matthijs@isc.org</a>>> a écrit :<br>
> <br>
>     Hi Adrien,<br>
> <br>
>     Without any logs or key **state** files, I can't really tell what is<br>
>     going on.<br>
> <br>
>     My only gut feeling is that you have never signaled BIND 9 that the DS<br>
>     has been published. You can run 'rndc dnssec -checkds -key 12345<br>
>     published <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> <<a href="http://example.com" rel="noreferrer" target="_blank">http://example.com</a>>' or set up<br>
>     parental-agents to do it for you.<br>
> <br>
>     Best regards,<br>
> <br>
>     Matthijs<br>
> <br>
>     On 1/17/23 09:38, adrien sipasseuth wrote:<br>
>      > Hello,<br>
>      ><br>
>      > I put the management of DNSSEC with KASP, the zone is well<br>
>     functional.<br>
>      > (dig with "AD" flag etc)<br>
>      ><br>
>      > On the other hand, I can't see when the key rollover period for<br>
>     my KSK<br>
>      > is over (2 KSKs with a dig DNSKEY...)<br>
>      ><br>
>      > Without KASP, it was easy because I generated the second KSK key but<br>
>      > with KASP, it is managed automatically.<br>
>      ><br>
>      > So, I have to adapt my scripts to check that there is :<br>
>      >   - a used KSK key and a next KSK key<br>
>      >   - Or only one KSK key used (if we are not in rollover phase)<br>
>      ><br>
>      > Except that with my current policy, I never see 2 KSKs via a "dig<br>
>      > DNSKEY...".<br>
>      > here is my policy :<br>
>      ><br>
>      > dnssec-policy "test" {<br>
>      >      keys {<br>
>      >          ksk lifetime P7D algorithm ecdsa256;<br>
>      >          zsk lifetime P3D algorithm ecdsa256;<br>
>      >      };<br>
>      >      purge-keys 1d;<br>
>      >      publish-safety 3d;<br>
>      >      retire-safety 3d;<br>
>      > };<br>
>      ><br>
>      > I see either my KSK in use or my next KSK (via "dig DNSKEY...") but<br>
>      > never both at the same time.<br>
>      ><br>
>      > Is this a normal behavior or am I doing it wrong?<br>
>      ><br>
>      > Regards, Adrien<br>
>      ><br>
>     -- <br>
>     Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
>     <<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>> to unsubscribe<br>
>     from this list<br>
> <br>
>     ISC funds the development of this software with paid support<br>
>     subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a><br>
>     <<a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a>> for more information.<br>
> <br>
> <br>
>     bind-users mailing list<br>
>     <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a> <mailto:<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>><br>
>     <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
>     <<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>><br>
> <br>
> <br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>