Hi Matthijs ,
my next key was generated yesterday as expected by policy (parameter
"publish-safety 3d;"). My current key has been deleted from Bind (according
to the logs) but it still exists on my primary server (I can still find the
key and its status file).
When I do a "dig DNSKEY ..." from the primary server I only see the next
KSK.
I published the DS of my next key at my registrar and I notified Bind that
it was done via the command: rndc dnssec -checkds -key 24167 published
***********************'
In the logs here is what I have :
janv. 24 17:55:03 named[1197184]: keymgr: DNSKEY
********************/ECDSAP256SHA256/24167 (KSK) created for policy
client-generique
janv. 24 17:55:03 named[1197184]: DNSKEY
********************/ECDSAP256SHA256/46358 (KSK) is now deleted
janv. 24 17:55:03 named[1197184]: Fetching
********************/ECDSAP256SHA256/24167 (KSK) from key repository.
janv. 24 17:55:03 named[1197184]: DNSKEY
********************/ECDSAP256SHA256/24167 (KSK) is now published
janv. 24 17:55:03 named[1197184]: zone ********************/IN (signed):
next key event: 24-Jan-2023 19:00:03.893
janv. 24 17:55:03 named[1197184]: zone ********************/IN (signed):
sending notifies (serial 2022123004)
......<not relevant logs>.....
janv. 24 17:55:08 named[1197184]: zone ********************/IN (signed):
sending notifies (serial 2022123005)
janv. 24 19:00:03 named[1197184]: zone ********************/IN (signed):
reconfiguring zone keys
janv. 24 19:00:03 named[1197184]: keymgr: purge DNSKEY
********************/ECDSAP256SHA256/13323 (ZSK) according to policy
client-generique
janv. 24 19:00:03 named[1197184]: DNSKEY
********************/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 24 19:00:03 named[1197184]: zone ********************/IN (signed):
next key event: 25-Jan-2023 17:55:03.897
janv. 25 09:11:34 named[1197184]: received control channel command 'dnssec
-checkds -key 24167 published ********************'
janv. 25 09:11:34 named[1197184]: keymgr: checkds DS for key
********************/ECDSAP256SHA256/24167 seen published at Wed Jan 25
09:11:34 2023
janv. 25 09:11:34 named[1197184]: zone ********************/IN (signed):
reconfiguring zone keys
janv. 25 09:11:34 named[1197184]: DNSKEY
********************/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 25 09:11:34 named[1197184]: zone ********************/IN (signed):
next key event: 25-Jan-2023 17:55:03.026
janv. 25 09:19:02 named[1197184]: received control channel command 'dnssec
-status ********************'
janv. 25 09:19:59 named[1197184]: zone ********************/IN (signed):
reconfiguring zone keys
janv. 25 09:19:59 named[1197184]: DNSKEY
********************/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 25 09:19:59 named[1197184]: zone ********************/IN (signed):
next key event: 25-Jan-2023 17:55:03.062
When I look at the state files of my 2 KSKs, I always have "DSState:
hidden", I can't find any documentation on it, how Bind decides that the DS
is hidden? Because my primary server is hidden (not exposed to internet)?
Here is a "dig DS ..." I can see my current key :
...
***********************. 104974 IN DS 46358 13 2 (
0715AC00A9C4349AA627F098A20B6716EE7334CBE261
34D6281B36453C99D6C2 )
....
If it can help , here are the contents of the status files of my 2 KSKs :
KSK current but deleted (according to Bind logs):
; This is the state of key 46358, for ***********************
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
Successor: 24167
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: 20230125082125 (Wed Jan 25 09:21:25 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230124180003 (Tue Jan 24 19:00:03 2023)
KRRSIGChange: 20230124180003 (Tue Jan 24 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: hidden
KRRSIGState: hidden
DSState: hidden
GoalState: hidden
The following KSK was generated, published at my registrar, notified to
Bind via the command "rndc dnssec -checkds..." and visible via a "dig
DNSKEY..." :
; This is the state of key 24167, for ***********************
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 46358
KSK: yes
ZSK: no
Generated: 20230124165503 (Tue Jan 24 17:55:03 2023)
Published: 20230124165503 (Tue Jan 24 17:55:03 2023)
Active: 20230127180003 (Fri Jan 27 19:00:03 2023)
Retired: 20230203180003 (Fri Feb 3 19:00:03 2023)
Removed: 20230207190003 (Tue Feb 7 20:00:03 2023)
DSPublish: 20230125082155 (Wed Jan 25 09:21:55 2023)
PublishCDS: 20230127180003 (Fri Jan 27 19:00:03 2023)
DNSKEYChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
KRRSIGChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
DSChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
DNSKEYState: rumoured
KRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent
Regards Adrien
Le mar. 24 janv. 2023 à 15:18, adrien sipasseuth <
sipasseuth.adr...@gmail.com> a écrit :
> Hello,
>
> I don't why DSState: hidden, it's ok with some online check tools like :
> - https://dnssec-analyzer.verisignlabs.com/
> - https://zonemaster.net/fr/run-test
>
> my master is hidden, it can be related ? How i can debug this DSState:
> hidden ?
>
> 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
> ...
>
> Regards Adrien
>
> Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking <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>> 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@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
