Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys

[Matthijs Mekking]

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.

Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys

[Petr Špaček]

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.


--
Petr Špaček
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list.

Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys

[Matthijs Mekking]

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

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 ' 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;
 >          };
 >      };

Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys

[Nagesh Thati]

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.

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.

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.

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.

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.

Thanks,
Nagesh

On Tue, Mar 17, 2026 at 2:53 PM Matthijs Mekking  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
>
> 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 ' 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 " IN {
> >  type master;
> >  file "/var/named/zones/db.dnssectest.com  > 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 

Re: [BIND-users] DNSSEC Key Management: Using dnssec-policy with Externally Generated Keys — KASP Auto-Retiring Newly Copied Keys

[Matthijs Mekking]

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

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 ' 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 " IN {
         type master;
         file "/var/named/zones/db.dnssectest.com 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



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-