Hi Bernd,
Sorry for taking a long time to answer these questions:
> 1) Timing Options:
>
> I didn't grasped yet all the defaults and their calculated interaction
> when I let `bind9` manage the signing keys for a zone, which in the end
> is just follows an RFC, if I'm right? I would like to "replicate" those
> timers manually. I hope I can answer this all by myself. However, the
> second question:
Correct.
>
> 2) Security Lameness
> Is it neutral or bad or even good, that I publish 2 DS RR in the parent
> zone, but using only 1 to sign my zone?
This happens anyway during a Double-DS rollover scheme, so I don't think
it is bad practice. A resolver may have to do a bit more work, but
negligible in my opinion.
- Matthijs
On 26-02-2025 00:13, Bernd Naumann wrote:
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
Hi Bernd,
Hey Matthijs,
Why not let us start all over again :) (I really do thank you so much
for taking the time!)
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
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.
In 9.20 this is fixed and you should be able to add the DNSKEY record to
the zone, even with inline-signing enabled.
Also note that dnssec-policy does not support RFC 5011 (yet).
Best regards,
Matthijs
For now I have to stick with 9.18 till I find the time to port my setup
to OpenWrt 24.10 which just got released...
See the mess in the other part of this thread... But I've made some
progress in between, and wanted to "start from scratch".
Yes, in the meantime I've gone back to manually signing the zone.
I've reread and reread RFC 6781 (DNSSEC Operational Practices, Ver. 2)
and RFC 7583 (DNSSEC Key Rollover Timing Considerations) over and over
again.
For now only 2 big questions remain for me (I hope):
1) Timing Options:
I didn't grasped yet all the defaults and their calculated interaction
when I let `bind9` manage the signing keys for a zone, which in the end
is just follows an RFC, if I'm right? I would like to "replicate" those
timers manually. I hope I can answer this all by myself. However, the
second question:
2) Security Lameness
Is it neutral or bad or even good, that I publish 2 DS RR in the parent
zone, but using only 1 to sign my zone?
In an emergency, (with respect to the timers and the procedures) I would
like *not to* perform a smooth roll-over, but to revoke my first KSK,
and publish+activate my second KSK, and then start signing with the
second one.
I struggle to answer that question -- about good behavior and practice
of the double-ds method for ksk -- just by the RFC.
Section 4.3.3. Security Lameness of RFC 6781, just continues to argue
about "what if we change the algo and can only verify the keyid", but
not what happens to a resolver trying to verify the second KSK which got
signed by the first KSK, and which was valid by time and hopefully still
is. And now KSK-1 is revoked and KSK-2 is active; or do I miss an
important detail here?
Anyhow: here is what I've found in regards to "easier" manual key handling:
* I can set a policy
```
dnssec-policy "example-ec" {
keys {
ksk lifetime P1Y algorithm ecdsa256;
zsk lifetime P60D algorithm ecdsa256;
};
purge-keys 0;
};
```
* I can generate with
```
dnssec-keygen \
-K /etc/bind/keys/ \
-l /etc/bind/named.conf \
-k example-ec example.dn42
```
my first KSK and ZSK (configured by an dnssec-policy); and
* I can generated with
```
dnssec-keygen \
-K /etc/bind/keys/ \
-l /etc/bind/named.conf \
-k example-ec -G example.dn42
```
my second KSK and ZSK. <!-- I removed the (second) ZSK, and ignored the
fact, that I've just generated the key material where I did it, and
where it shouldn't belong, I know; but for now it's for illustrating
purpose only.
So I move the second KSK `.private`-file away. -->
* I then include all 3 `.key`-files in the zone:
```
# cat \
Kexample.dn42.+013+20716.key \
Kexample.dn42.+013+50229.key \
Kexample.dn42.+013+63211.key
; This is a key-signing key, keyid 20716, for example.dn42.
; Created: 20250225210944 (Tue Feb 25 21:09:44 2025)
; Publish: 20250225210944 (Tue Feb 25 21:09:44 2025)
; Activate: 20250225210944 (Tue Feb 25 21:09:44 2025)
example.dn42. 3600 IN DNSKEY 257 3 13
JEzPiezWJWmdmJW8j7BU34oe42rZA84mCwfED68a3HC/Yl421NtFyo0k
iJNcFA589TWejXmljKrekYTuBuMCjg==
; This is a zone-signing key, keyid 50229, for example.dn42.
; Created: 20250225210944 (Tue Feb 25 21:09:44 2025)
; Publish: 20250225210944 (Tue Feb 25 21:09:44 2025)
; Activate: 20250225210944 (Tue Feb 25 21:09:44 2025)
example.dn42. 3600 IN DNSKEY 256 3 13
P9O8vrbPeGfwWXLLc2Kki28bqWWKHg58EnZkF4GNEFn9uzECnaQAzGbV
KN+hUxA8NwwqBfSZ0p5OJF+PCERzBw==
; This is a key-signing key, keyid 63211, for example.dn42.
; Created: 20250225211606 (Tue Feb 25 21:16:06 2025)
example.dn42. 3600 IN DNSKEY 257 3 13
bCiZYh9cbWh3D3g5MildBT53zdxE79GNYwmC1CUiEFCNW1s9jWujFfFN
aV0vgI5DgzTRGBY6zrpnQdbEzZctjA==
```
* Now, I can use `dnssec-signzone -S`
```
dnssec-signzone \
-S \
-K /etc/bind/keys/ \
-d /etc/bind/ \
-o example.dn42 -N INCREMENT \
/etc/bind/db.dn42.example
dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading
/etc/bind/keys/Kexample.dn42.+013+63211.private: file not found
dnssec-signzone: info: DNSKEY example.dn42/ECDSAP256SHA256/20716 (KSK)
is now active
dnssec-signzone: info: DNSKEY example.dn42/ECDSAP256SHA256/50229 (ZSK)
is now active
dnssec-signzone: example.dn42/NSEC:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
dnssec-signzone: example.dn42/DNSKEY:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/20716
dnssec-signzone: example.dn42/SOA:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
dnssec-signzone: example.dn42/NS:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
dnssec-signzone: ns1.example.dn42/NSEC:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
dnssec-signzone: ns1.example.dn42/AAAA:
dnssec-signzone: signing with dnskey
example.dn42/ECDSAP256SHA256/50229
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 1 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db.dn42.example.signed
Signatures generated: 7
Signatures retained: 0
Signatures dropped: 0
Signatures successfully verified: 0
Signatures unsuccessfully verified: 0
Signing time in seconds: 0.000
Runtime in seconds: 0.149
```
* I am able to retrieve both DNSKEY type 257 / DS
```
# (d=example.dn42; dig @ns1.bernd.dn42 +norecurse "${d}". DNSKEY |
dnssec-dsfromkey -f - "${d}")
example.dn42. IN DS 20716 13 2
729518C1A7FCDFC426662F618D6929E23102F23C359C9E455427ED78888CFC3E
example.dn42. IN DS 63211 13 2
271BD48C37C31D7DF62D74A97E9EA1ADBFDC50978C24F54AD9F6D70A711996AF
```
My next step is to get (again) into timers, and find something low
enough to be able to roll maybe once or twice a day for now.
(Like as described in
https://datatracker.ietf.org/doc/html/rfc6781#section-4.2 Planning for
Emergency Key Rollover)
I want to see if Smart Signing helps here with the zone management.
Based on the Timers I set, I want to manually generate new keys, based
on the dnssec-policy; i.e. either revoke a KSK, or doing a "smooth"
roll-over, to see how "huge" the manually maintenance overhead could be...
Thanks Matthijs and everyone else taking the time reading so far!
I would be really thankful for feedback in form of either confirmation
or pointing out errors or misunderstandings on my side; or "violating" BCP.
Best,
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
