Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys
Matthijs Mekking
matthijs at isc.org
Thu Mar 19 09:18:58 UTC 2026
Hi Nagesh,
Please seem my comments inline.
On 3/18/26 13:11, Nagesh Thati wrote:
> Hello Matthijs,
>
> 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.
> 3. BIND's KASP engine correctly treats keys generated with -G as
> successor candidates and manages all timing, pre-publication, and
> activation automatically based on the dnssec-policy configuration.
> > One additional observation that may be useful to others: copying
> successor keys too early (well before the rollover window) causes BIND
> to set GoalState: hidden on the new keys, effectively rejecting them.
> The successor key should be copied within a reasonable window before the
> scheduled rollover — not immediately after the current key is activated.
The GoalState and other states on pregenerated keys are initialized to
hidden. That should not prevent those keys from being selected as a
successor.
In other words, it shouldn't matter when you copy the keys to the
key-directory. If you observed differently, please provide a reproducer
and create a new issue:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new
> We are now successfully using this approach to externally manage DNSSEC
> key generation while letting BIND handle all signing, re-signing, and
> rollover operations automatically via dnssec-policy.
Great to hear!
Do you have any recommendations on how to improve our documentation, to
avoid common pitfalls for others?
> Thank you again for the guidance and for pointing us to the relevant
> section of the ISC Knowledge Base. It made a significant difference in
> our implementation.
Glad I could be of assistance,
Best regards,
Matthijs
> Thanks,
> Nagesh
>
> On Tue, Mar 17, 2026 at 2:53 PM Matthijs Mekking <matthijs at isc.org
> <mailto:matthijs at isc.org>> wrote:
>
> Hello Nagesh,
>
> This should be possible, this section of the KB article should be of
> interest to you:
>
> https://kb.isc.org/docs/dnssec-key-and-signing-policy#importing-
> dnssec-keys <https://kb.isc.org/docs/dnssec-key-and-signing-
> policy#importing-dnssec-keys>
>
> The takeaway is that you should not set timing metadata in the key
> files
> (other than Created). Keys without timing metadata are considered
> pregenerated keys and are eligible candidates to become successor keys.
>
> Also don't set "Predecessor"/"Successor" metadata, dnssec-policy will
> set those when selecting a successor key.
>
> Furthermore, depending on what 9.18 version you are running, there may
> be bugs in older versions that cause existing keys to retire too soon.
>
>
> On 3/17/26 06:02, Nagesh Thati wrote:
> > Hello BIND Community,
> >
> > I am working on a solution that integrates with BIND 9.18 for
> DNSSEC key
> > management. I would like to share a behavior I have observed and
> seek
> > guidance from the community on the best approach.
> >
> >
> > Background
> > ==========
> >
> > Our architecture is as follows:
> >
> > - My solution is responsible for generating DNSSEC keys (KSK and
> ZSK)
> > using dnssec-keygen.
> > - The generated keys are copied to the BIND key directory
> configured via
> > the key-directory directive.
> > - BIND is configured with dnssec-policy to handle automatic zone
> signing
> > and re-signing.
> > - My solution monitors key Inactive times and generates new
> replacement
> > keys ahead of rollover, copying them to the key directory when
> rollover
> > time approaches.
> > - We then run 'rndc loadkeys <zone>' to signal BIND to pick up
> the new keys.
> >
> > Our dnssec-policy configuration is as follows:
> >
> > dnssec-policy "managed-keys" {
> > keys {
> > ksk lifetime P365D algorithm ecdsap256sha256;
> > zsk lifetime P30D algorithm ecdsap256sha256;
> > };
> > };
> > zone "dnssectest.com <http://dnssectest.com> <http://
> dnssectest.com <http://dnssectest.com>>" IN {
> > type master;
> > file "/var/named/zones/db.dnssectest.com <http://
> db.dnssectest.com> <http://
> > db.dnssectest.com <http://db.dnssectest.com>>";
> > key-directory "/var/named/keys";
> > inline-signing yes;
> > dnssec-policy "managed-keys";
> > };
> >
> > Observed Issue
> > ==============
> >
> > When testing our key rollover logic, we simulate an approaching
> expiry
> > by manually changing the Inactive time of the current ZSK or KSK
> to 2-3
> > days from now. We then generate a new replacement key and copy it
> to the
> > key directory, followed by running 'rndc loadkeys'.
> >
> > The observed behavior is:
> >
> > 1. For ZSK rollover: BIND's KASP engine detects the newly copied
> ZSK in
> > the key directory and automatically retires it, instead of
> treating it
> > as the incoming replacement key.
> >
> > 2. For KSK rollover: The same behavior is observed — the newly
> copied
> > KSK is auto-retired by KASP shortly after being picked up.
> >
> > This appears to happen because BIND's KASP engine takes ownership
> of all
> > keys present in the key directory and manages their lifecycle
> > independently, overriding the timing metadata we have set on the
> newly
> > copied keys.
> >
> >
> > Questions
> > =========
> >
> > 1. Is there a supported way to use dnssec-policy while having an
> > external application manage key generation and rollover, with
> BIND only
> > responsible for signing and re-signing?
>
> No. BIND can do DNSSEC maintenance for you, or you have to do key and
> signature maintenance manually with dnssec-signzone.
>
> Your best choice is to set key lifetimes to unlimited, and when
> there is
> a new key rollover, drop the key files into the configured key-
> directory
> and issue a 'rndc dnssec -rollover' command.
>
>
> > 2. Is there a mechanism to signal to BIND's KASP engine that a newly
> > copied key should be treated as a pre-publication replacement key
> for an
> > upcoming rollover, rather than a new independent key?
>
> As you have experienced, excess keys with key timing metadata will be
> retired. Try copying the key files of the successor key without setting
> timing metadata.
>
> > 3. Does BIND 9.18's KASP engine honor the Publish, Activate,
> Inactive,
> > and Delete timing metadata set on externally generated keys when
> they
> > are copied to the key directory, or does it always recalculate and
> > override these values based on the active dnssec-policy?
>
> Nope. BIND will set those timing metadata given the dnssec-policy.
> It is
> merely used to inform the user when it can expect a key to become
> published, active, inactive and removed from the zone.
>
>
> > 4. Is the 'auto-dnssec maintain' directive (without dnssec-
> policy) still
> > a viable option for this use case in BIND 9.18, given that it is
> > deprecated? Are there plans to remove it in an upcoming release?
>
> It is already removed in 9.20, so I wouldn't consider it viable.
>
>
> > 5. Are there any plans in future BIND versions to support an
> "external
> > key provider" interface or a "bring your own key" (BYOK) model
> within
> > the KASP framework?
>
> It should work as I described above.
>
> If not, feel free to create an issue in our GitLab:
> https://gitlab.isc.org/isc-projects/bind9/-/issues/new <https://
> gitlab.isc.org/isc-projects/bind9/-/issues/new>
>
>
> Best regards,
>
> Matthijs
>
>
> > What We Have Tried
> > ==================
> >
> > - Using 'lifetime unlimited' in dnssec-policy to prevent BIND
> from auto-
> > generating replacement keys. However, BIND still auto-retires newly
> > copied keys when it detects them in the key directory.
> >
> > - Using 'auto-dnssec maintain' with 'inline-signing yes' without
> dnssec-
> > policy. This works correctly and respects our key timing
> metadata, but
> > we are concerned about relying on a deprecated directive for a
> > production system.
> >
> > - Manually editing the .private file and running 'rndc loadkeys'.
> BIND
> > picks up the timing changes but KASP still overrides the lifecycle
> > management of newly added keys.
> >
> >
> > Environment
> > ===========
> >
> > - BIND Version: 9.18.x
> > - OS: Alma Linux
> > - Key Algorithm: ECDSAP256SHA256
> > - ZSK Lifetime: 30 days
> > - KSK Lifetime: 365 days
> >
> >
> > Any guidance, suggestions, or pointers to relevant documentation or
> > discussions would be greatly appreciated. We want to ensure our
> > implementation is aligned with BIND's intended design and is
> forward-
> > compatible with future releases.
> >
> > Thank you for your time and assistance.
> >
> > Best regards
> > Nagesh
> >
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users <https://
> lists.isc.org/mailman/listinfo/bind-users> to unsubscribe from this
> list.
>
More information about the bind-users
mailing list