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 <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>" IN {
>          type master;
>          file "/var/named/zones/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


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
>