Questions about automatic KSK and using an additional stand-by KSK
Matthijs Mekking
matthijs at isc.org
Mon Mar 3 14:18:29 UTC 2025
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
>
>
More information about the bind-users
mailing list