This time I was able to reproduce, thanks.
The reason why the key created by dnssec-keygen is retired because named
thinks it was in use already. When there is key timing metadata, the key
is considered to be in use (now or in the past).
Only not previously used keys are considered as a successor in key
rollovers.
Try generating the key with dnssec-keygen -G. This will create a key
without setting timing metadata.
I will update the documentation accordingly.
Best regards,
Matthijs
On 4/8/25 05:43, Bagas Sanjaya wrote:
On Mon, Apr 07, 2025 at 09:28:07AM -0500, Matthijs Mekking wrote:
Hi,
I have tried to reproduce but when I am issuing a rollover it selects the
key I generate previously, as expected.
If you believe this is a genuine bug, please support a bug report:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Default
and fill in the steps how to reproduce the issue.
Any logs (preferably debug level 3) would then also be greatly appreciated.
Thanks, best regards,
Matthijs
On 3/26/25 14:51, Nguyen Thi Minh Tam via bind-users wrote:
"Hi, I'm trying version 9.18.31.
According to the post on
https://kb.isc.org/docs/dnssec-key-and-signing-policy
<https://kb.isc.org/docs/dnssec-key-and-signing-policy>, the policy
normally generates keys when they are needed. However, we can generate
the DNSSEC keys ourselves first, and when the policy requires a new key,
it will select the one we created.
There is even an example in that post.
So, I followed that approach. I generated a new key that matches the
policy and placed it in the key directory. However, when it was time to
roll the key, my key was retired, and the policy generated a new one
instead.
Here is my policy:"
dnssec-policy "hosting key" {
dnskey-ttl PT1M;
keys{
ksk key-directory lifetime P1Y algorithm RSASHA256 2048;
zsk key-directory lifetime P30D algorithm RSASHA256 2048;
};
And i run this command to generate the next key:
dnssec-keygen -a 8 -b 2048 -n ZONE -K /data/keys/policy.com/ policy.com
i even tried
dnssec-keygen -k "hosting key" -l /etc/named.conf -K
/data/keys/policy.com/ policy.com
Hi Matthijs, Hi Nguyen,
I can reproduce the bug, using Nguyen's dnssec-policy.
Before the rollover, I pregenerate the explicit successor ZSK by:
```
$ cd /var/named
# dnssec-keygen -a rsasha256 -b 2048 -f zsk test.net
# chown named:named Ktest.net.+008+07213*
```
``rndc dnssec -status test.net`` shows that the successor key (07213) isn't
recognized:
```
dnssec-policy: test
current time: Tue Apr 8 10:25:50 2025
key: 36679 (RSASHA256), KSK
published: yes - since Tue Apr 8 10:14:10 2025
key signing: yes - since Tue Apr 8 10:14:10 2025
Next rollover scheduled on Wed Apr 8 08:09:10 2026
- goal: omnipresent
- dnskey: rumoured
- ds: rumoured
- key rrsig: rumoured
key: 50448 (RSASHA256), ZSK
published: yes - since Tue Apr 8 10:14:10 2025
zone signing: yes - since Tue Apr 8 10:14:10 2025
Next rollover scheduled on Fri May 9 08:09:10 2025
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: rumoured
key: 7213 (RSASHA256), UNKNOWN
published: no
No rollover scheduled
```
I trigger the rollover by ``rndc dnssec rollover -key 50448 -when
20250408103000`` and the dnssec status shows that a new ZSK key is introduced
instead:
```
dnssec-policy: test
current time: Tue Apr 8 10:30:37 2025
key: 36679 (RSASHA256), KSK
published: yes - since Tue Apr 8 10:14:10 2025
key signing: yes - since Tue Apr 8 10:14:10 2025
Next rollover scheduled on Wed Apr 8 08:09:10 2026
- goal: omnipresent
- dnskey: rumoured
- ds: rumoured
- key rrsig: rumoured
key: 50448 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: unretentive
- zone rrsig: unretentive
key: 7213 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: unretentive
- zone rrsig: unretentive
key: 19861 (RSASHA256), ZSK
published: yes - since Tue Apr 8 10:30:00 2025
zone signing: yes - since Tue Apr 8 12:35:00 2025
Next rollover scheduled on Fri May 9 10:30:00 2025
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: rumoured
```
The log from systemd journal:
```
Apr 08 10:15:25 test.mydns.me named[174]: keymgr: checkds DS for key
test.net/RSASHA256/36679 seen published at Tue Apr 8 10:15:25 2025
Apr 08 10:15:25 test.mydns.me named[174]: zone test.net/IN (signed):
reconfiguring zone keys
Apr 08 10:15:25 test.mydns.me named[174]: CDS (SHA-256) for key
test.net/RSASHA256/36679 is now published
Apr 08 10:15:25 test.mydns.me named[174]: CDNSKEY for key
test.net/RSASHA256/36679 is now published
Apr 08 10:15:26 test.mydns.me named[174]: zone test.net/IN (signed): next key
event: 08-Apr-2025 12:19:10.937
Apr 08 10:18:38 test.mydns.me named[174]: received control channel command
'dnssec -status test.net'
Apr 08 10:25:50 test.mydns.me named[174]: received control channel command
'dnssec -status test.net'
Apr 08 10:27:47 test.mydns.me named[174]: received control channel command
'dnssec -rollover -key 50448 -when 20250408103000 test.net'
Apr 08 10:27:47 test.mydns.me named[174]: zone test.net/IN (signed):
reconfiguring zone keys
Apr 08 10:27:47 test.mydns.me named[174]: keymgr: retire DNSKEY
test.net/RSASHA256/7213 (ZSK)
Apr 08 10:27:47 test.mydns.me named[174]: zone test.net/IN (signed): next key
event: 08-Apr-2025 10:30:00.592
Apr 08 10:27:56 test.mydns.me named[174]: received control channel command
'dnssec -status test.net'
Apr 08 10:30:00 test.mydns.me named[174]: zone test.net/IN (signed):
reconfiguring zone keys
Apr 08 10:30:00 test.mydns.me named[174]: keymgr: DNSKEY
test.net/RSASHA256/19861 (ZSK) created for policy test
Apr 08 10:30:00 test.mydns.me named[174]: Removing expired key
test.net/50448/RSASHA256 from DNSKEY RRset.
Apr 08 10:30:00 test.mydns.me named[174]: DNSKEY test.net/RSASHA256/50448 (ZSK)
is now deleted
Apr 08 10:30:00 test.mydns.me named[174]: Fetching test.net/RSASHA256/19861
(ZSK) from key repository.
Apr 08 10:30:00 test.mydns.me named[174]: DNSKEY test.net/RSASHA256/19861 (ZSK)
is now published
Apr 08 10:30:00 test.mydns.me named[174]: DNSKEY test.net/RSASHA256/19861 (ZSK)
is now active
Apr 08 10:30:01 test.mydns.me named[174]: zone test.net/IN (signed): next key
event: 08-Apr-2025 11:32:47.720
```
Thanks.
--
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