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 <matth...@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 <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 >
-- 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
