Hi Bernd,
On 24-02-2025 10:12, Bernd Naumann wrote:
Hi Matthijs, thanks for your response.
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
Hi Bernd,
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
Yeah I figured that in the mean time :/
But what I don't understand; RFC 7583 explicit mentioned pre-publish of
DSDATA of ZSK, but not for KSK (IIUC)?
And I am confused about the phrase "DSDATA of ZSK".
(Or is the 'market-share' of standby keys that low and most people using
a single KSK/ZSK and doing automatic roll over? How high is the chance
anyway to need an emergency key revocation and key rotation?)
Since the introduction of dnssec-policy in 9.16 I haven't had a request
for stand-by keys.
Now, I wanted to test an KSK roll over with the following procedure.
* gen KSK-1; gen ZSK-1; gen KSK-2 (offline)
* Add KSK-1, KSK-2, ZSK-1 to the zone
* Sign DNSKEY with KSK-1; sign zone with ZSK-1
* Publish 2x DS for DNSKEY 257
* activate KSK-2; revoke KSK-1; sign DNSKEY with KSK-2 and sign zone
with ZSK-1
In 9.18, I would suggest to disable inline-signing and just add the
DNSKEY record to the zone. Don't put the key files for the stand-by key
in the 'key-directory', this should only hold signing keys.
Jep I've done that; except "Don't put the key files for the stand-by key
in the 'key-directory'". You the `.private` and `.state` file? (I
added either the `.key` and on a second run `.key` and `.state`.)
I mean no key files at all. Non-signing keys shouldn't have key files,
otherwise they are considered to be signing keys (which is what you
don't want with a standby key).
In 9.20 this is fixed and you should be able to add the DNSKEY record to
the zone, even with inline-signing enabled.
K, lets see if I got 9.20 for OpenWrt. (Or I need to test on Debian)
Also note that dnssec-policy does not support RFC 5011 (yet).
I'm not sure I understand what you say? How does dnssec-policy interact
with 5011? (Or are you talking about, that a new auto generated key got
auto added to trust-anchros?)
I mean that dnssec-policy has no ability to revoke the key. Also
dnssec-policy is authoritative server specific, so it does not do
anything with trust-anchors.
The resolver code does support RFC 5011.
I've added my KSK to the trust-anchor as initial-key and `rdnc
manged-keys` picked that up... (Btw: Can I change to
30-day-delay-till-trust-established? Like to 1 days for testing purpose?)
Yes that should all work.
Best regards,
Matthijs
Thanks again,
Bernd
Best regards,
Matthijs
On 21-02-2025 12:32, Bernd Naumann wrote:
I've followed the ARM and the DNSSEC Guide, as well as some ISC KB blog
posts.
What I got working on BIND 9.18.33:
* adding a dnsssec-policy
* adding a zone using that dnssec-policy
- setting only SOA, NS, and the AAAA for NS for a minimal zone
* reload zone
I got an KSK and ZSK; the zone got signed; I added the KSK to
`trust-anchors` as an `initial-key`, and saw that the key got /managed/.
So far so good.
```
dnssec-policy "dn42-ec" {
keys {
ksk lifetime P1Y algorithm ecdsa256;
zsk lifetime P60D algorithm ecdsa256;
};
purge-keys 0;
};
zone "example.dn42" {
type primary;
file "/etc/bind/db.dn42.example";
dnssec-policy dn42-ec;
inline-signing yes;
allow-transfer {
fd00::/8;
};
};
```
```
# cat /etc/bind/keys/Kexample.dn42.+013+03829.key
; This is a key-signing key, keyid 3829, for example.dn42.
; Created: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Publish: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Activate: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Inactive: 20260220195943 (Fri Feb 20 19:59:43 2026)
; Delete: 20260221215943 (Sat Feb 21 21:59:43 2026)
; SyncPublish: 20250221210443 (Fri Feb 21 21:04:43 2025)
example.dn42. 3600 IN DNSKEY 257 3 13
pMlQUzpKNh2rgEh+DsazO8AiOHKFSpIvUltNPufKR26CugUU1p/1E8fi
atOqnOKIqUqrW+EJF/+RrgDPxfhW/A==
# cat /etc/bind/keys/Kexample.dn42.+013+41655.key
; This is a zone-signing key, keyid 41655, for example.dn42.
; Created: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Publish: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Activate: 20250220195943 (Thu Feb 20 19:59:43 2025)
; Inactive: 20250421195943 (Mon Apr 21 19:59:43 2025)
; Delete: 20250501210443 (Thu May 1 21:04:43 2025)
example.dn42. 3600 IN DNSKEY 256 3 13
oRwtJvxmISF4H9eMXkbqgL87muMvwP/D3v+dzki0GoYhl3d7OD03Jaeg
ykM+Qra0swAGHNfpprwsmjiOL7J00Q==
```
I then generated an stand-by key `dnssec-keygen -G` and included it to
the zone.
I tried sync, freeze, /update/, reload, thaw; and
I tried to `update add` the DNSKEY Record.
But, my issue is now: **I don't see the second KSK in the zone.**
I went through the manual generation and sign process and IIRC adding a
second KSK and seeing afterwards 2x KSK and 1x ZKS wasn't an issue.
What mistakes I do when trying to add a stand-by KSK to a auto-managed
zone? Or do I need to stick with the manual update and signing process?
(In the end I want to have the second KSK known to resolver so they can
manage (rfc 5011) that key for later revocation and roll-over events.)
Thanks.
Bernd
--
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
