Re: [BIND-users] DNSSEC Key Management: Using dns sec-policy with Externally Generated Keys — KASP Auto-Ret iring Newly Copied Keys

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 <[email protected] 
> <mailto:[email protected]>> 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.
> 

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.