Questions about automatic KSK and using an additional stand-by KSK

[Matthijs Mekking]

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
>>>
>>>
> 
>