On 1/24/23 15:18, adrien sipasseuth wrote:
Hello,
I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/
<https://dnssec-analyzer.verisignlabs.com/>
- https://zonemaster.net/fr/run-test <https://zonemaster.net/fr/run-test>
DSState: hidden is what BIND thinks. Note that it does not query yet to
determine the DSState.
my master is hidden, it can be related ? How i can debug this DSState:
hidden ?
It has nothing to do with hidden primaries.
I found this command to check actual status : rndc dnssec -status **********
This is the output :
....
key: 46358 (ECDSAP256SHA256), KSK
published: yes - since Tue Jan 17 17:55:03 2023
key signing: yes - since Tue Jan 17 17:55:03 2023
Next rollover scheduled on Tue Jan 24 17:55:03 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: hidden
- key rrsig: omnipresent
It is hard to determine why your DS is hidden. If all other elements are
omnipresent, the DS should be rumoured (because you may submit it to the
parent).
I have a feeling this is because your publish-safety is 3 days. It takes
an additional 3 days before continuing with the rollover, thus also with
"making the DS known to the world". In other words, I think BIND does
not yet think it is safe to publish the DS, hence DS is hidden.
I understand this may not reflect the real world, and perhaps it is a
bug. If someone issues a "rndc dnssec -checkds published" command", we
probably should force move the DS state from "hidden" to "rumoured".
Best regards,
Matthijs
...
Regards Adrien
Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking <matth...@isc.org
<mailto:matth...@isc.org>> a écrit :
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 <matth...@isc.org
<mailto:matth...@isc.org>
> <mailto:matth...@isc.org <mailto:matth...@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>
<http://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>
> <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/>
> <https://www.isc.org/contact/ <https://www.isc.org/contact/>>
for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
<mailto:bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>>
> https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>
> <https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>>
>
>
--
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@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
