[KASP] Key rollover
adrien sipasseuth
sipasseuth.adrien at gmail.com
Wed Feb 8 16:17:25 UTC 2023
Hello,
I waited 24 hours and then put my zone back in dnssec.
after 24 everything seems ok... at least by doing a "rndc dnssec -status
...."
everything is in omnipresent:
Next rollover scheduled on Fri Feb 10 09:15:51 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
so it works BUT I need to know more than 48h in advance that the rollover
is starting to submit the new KSK to my registar.
How can I set this up if it's not with "public-safety"?
Regards,
Adrien
Le mer. 25 janv. 2023 à 11:34, Matthijs Mekking <matthijs at isc.org> a écrit :
>
>
> 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 <matthijs at isc.org
> > <mailto:matthijs at 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 <matthijs at isc.org
> > <mailto:matthijs at isc.org>
> > > <mailto: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>
> > <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 at lists.isc.org <mailto:bind-users at lists.isc.org>
> > <mailto: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>
> > > <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 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>
> >
> >
> --
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230208/e79c830d/attachment-0001.htm>
More information about the bind-users
mailing list