On 3/19/26 10:59, Petr Špaček wrote:
On 19. 03. 26 10:18, Matthijs Mekking wrote:
On 3/18/26 13:11, Nagesh Thati wrote:
I wanted to follow up on my earlier question regarding using dnssec-
policy with externally generated keys in BIND 9.18.35 and share that
the suggested approach worked successfully.
To summarize what worked for our implementation:
1. Using the -G flag with dnssec-keygen to generate pregenerated keys
with no timing metadata (only the Created field is present). This was
the key insight we were missing — our keys previously had full timing
metadata which caused BIND's KASP engine to mishandle them.
Sounds good.
2. Copying the pregenerated keys to the key directory and running
'rndc loadkeys' is sufficient for BIND to detect and schedule the
rollover automatically. There is no need to run 'rndc dnssec -
rollover' for normal lifecycle rollovers — doing so prematurely
caused immediate key deletion in our testing, bypassing the double-
signature phase entirely.
Correct. Only if you have key lifetime unlimited, you will need to run
'rndc dnssec -rollover'. Some operators like to control when they
start rolling their key (external to BIND 9), but you can rely on
dnssec- policy's key lifetime, as long as you pregenerate the keys
before the successor needs to be pre-published.
Wondering out loud:
Could the new 'manual' mode in dnssec-policy be even better? It would
prevent any automatic change at all, resulting in better external control.
It's a trade off between operational complexity and control.
With manual-mode you will have to examine logs and issue rndc commands
manually to progress rollovers.
Also with manual-mode you still have to put pregenerated keys in the
key-directory if you don't want BIND to create them.
- Matthijs
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
