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