Hi Matthijs
I've tried several times to reproduce this behavior..., dnssec-policy
always does his job. I did not currently succeed in reproducing the
behavior. I will make a few more attempts and otherwise inform you.
Thank you.
Best regards,
Tom
On 29.11.21 10:56, Matthijs Mekking wrote:
Hi Tom,
On 29-11-2021 09:36, Tom wrote:
Hi
Using BIND-9.16.22:
After some tests with the new KASP feature, I'm running in a issue,
where BIND isn't signing the zone anymore.
In the old fashion way (auto-dnssec maintain;), I was able - under
some circumstances - to remove the ".signed" and ".signed.jnl" and
.jnl-files, restart BIND and everything was fine, the zone was signed
automatically with the existing keys.
In the special case now, I removed the ZSK key files and removed all
.signed and .signed.jnl and .jnl-files for a zone (like in the old
way). The KSK is still existing, a new ZSK is created through the
"dnssec-policy":
The dnssec-policy checks the key files against the policy. If you remove
the ZSK key files, it has no ZSK any longer while the policy dictates
so. That's why it will create a new ZSK.
In other words, don't remove your key files.
(Removing .signed and .jnl files should be fine and be recreated).
## BIND detects the already existing KSK, but logs a warning the the
KSK is missing or inactive.
29-Nov-2021 07:28:25.653 dnssec: info: keymgr: DNSKEY
example.ch/ECDSAP256SHA256/27534 (ZSK) created for policy
thewaytogo-faster
29-Nov-2021 07:28:25.654 dnssec: info: Fetching
example.ch/ECDSAP256SHA256/61416 (KSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/61416 (KSK) is now published
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/61416 (KSK) is now active
29-Nov-2021 07:28:25.654 dnssec: info: Fetching
example.ch/ECDSAP256SHA256/27534 (ZSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/27534 (ZSK) is now published
29-Nov-2021 07:28:25.654 general: info: CDS for key
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.654 general: info: CDNSKEY for key
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.659 dnssec: info: zone example.ch/IN (signed):
next key event: 29-Nov-2021 09:33:25.641
29-Nov-2021 07:28:25.660 general: warning: zone example.ch/IN
(signed): Key example.ch/ECDSAP256SHA256/61416 missing or inactive and
has no replacement: retaining signatures.
I am not able to reproduce this. Is this after a restart or a reload?
Perhaps it's better to report an issue on our gitlab:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new
Please provide the steps to reproduce and logs with debug level 3.
Best regards,
Matthijs
## But the KSK (61416) is existing and seems signing
$ rndc dnssec -status example.ch
dnssec-policy: thewaytogo-faster
current time: Mon Nov 29 09:10:42 2021
key: 61416 (ECDSAP256SHA256), KSK
published: yes - since Tue Oct 12 16:50:17 2021
key signing: yes - since Tue Oct 12 16:50:17 2021
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 27534 (ECDSAP256SHA256), ZSK
published: yes - since Mon Nov 29 07:28:25 2021
zone signing: no
Next rollover scheduled on Mon Dec 6 05:23:25 2021
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: hidden
So, BIND detects the already existing KSK and ZSK, but is not able to
sign the dnskey-rrset with the KSK or some TXT-records with the ZSK.
## DNSKEY RR are existing, the RRSIG is missing
$ dig +short @127.0.0.1 +norec +dnssec dnskey example.ch
256 3 13 3YU6kADe6IRhJ2rcmHOrPgH6tq/7PQQP7VpLBA70p/bPQFPRagdxuGdl
XrDg7tQ9WTr553BA5dUGqRBEYYQTUw==
257 3 13 bT4QClt+P9+t1+vF/Ulj7DSISBVMV86TktfNqheiUVGqfZ2hsEpYP140
flVurgV17M/nzujoMW0KgyTuP3p4Kw==
The dnssec-policy looks like this:
dnssec-policy "thewaytogo-faster" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 30d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 7d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
When running "rndc sign example.ch", then nothing happens -> I'm not
sure, if "rndc sign" is still possible with "dnssec-policy"...?
Any hints, how I can recover this state to a working signing-state
without recreating a new KSK?
I assume, that disabling DNSSEC completely and creating a new ZSK/KSK
will work, but in the case now, I already have the mentioned KSK (61416).
Thank you.
Kind regards,
Tom
_______________________________________________
Please 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
_______________________________________________
Please 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
_______________________________________________
Please 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
