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

[Matthijs Mekking]

On 24-02-2025 11:51, Bernd Naumann wrote:
...

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

The short answer is: history.

A private key file may become inaccessible (disk read error, offline 
KSK, ...) and we don't want to replace that key at that point. So the 
existence of a public key file signals this is a signing key.

A signing key that is not active is considered a signing key because it 
is likely to be so in the future (for example it is being pre-published 
right now).



> (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 fail to parse this question, sorry.



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

That's right.


> (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?)

Most users won't need RFC 5011. Folks that do usually are smart enough 
to come up with their own signing solutions.

But that does not mean we won't support it in the future. We just didn't 
get to it yet and it wasn't high on the priority list. People asking for 
it will likely bump it higher up the list though.


Best regards,

Matthijs


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