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

[Bernd Naumann]

On 24.02.25 11:22 AM, Matthijs Mekking wrote:

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

Sorry I'm not fully confident yet about the wording here and there...
I thing I wanted to say DS RR: (see
https://www.rfc-editor.org/rfc/rfc7583.html)

> https://www.rfc-editor.org/rfc/rfc7583.html#section-4
>  [...]
>  Finally, in the Double-DS method of rolling a KSK, it is not a
>  standby key that is present, it is a standby DS record in the parent
>  zone.
>  [...]

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

Mhm. But *how* is *everyone else* using DNSSEC then?

I really like the automatic key handling, but I fail to see how someone
should then react in an emergency case, where its time critical to roll
the keys over.

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

Could you give me a pointer where to get the details/rationale? I have
to impression that some of the fundamentals are missing.
Why is a "key" considered a "signing key" even:
* The (public) `.key` has no `.private` available (so signing is not
even possible with that "key")
* Why is a key considered a signing key, even it is not active?

(Also I'm still fail to understand/see what changes I set various key
flags with the bind tools. Is it only a text-info in the state fail or
is something actually changed in the key?

I was under the impression that when doing manual signing that the Smart
Signing Feature of `dnssec-signzone` should handle such use cases (1
active KSK and ZSK and standby KSK).

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

Ok, so, if using dnssec-policy a KSK or ZSK is never gonna be revoked by
`named`, but the key is just fading out, because the valid lifetime
reaches its end?

(If I may bother you a little bit more: Whats the issue with revoking a
key by the dnssec-policy? But `named` and the key management should
detect that a key got revoked?)

> 
>> 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 for your help!
Bernd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250224/09638952/attachment.sig>