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

[Nagesh Thati]

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

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?

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?

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?

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?


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260317/5ed4d93c/attachment.htm>