Removing expired key when it is not yet retired

Matthijs Mekking matthijs at isc.org
Thu Jul 9 08:27:35 UTC 2026


Hi,

 From your message it is hard to understand what you are trying to do? 
Are you migrating to dnssec-policy? Or are you experiencing this during 
key rollover?

In any case, if you believe there is a bug, please submit it to:

   https://gitlab.isc.org/isc-projects/bind9/-/work_items

Use the bug template, and fill in the necessary details (version, steps 
to reproduce, logs, ...)

Best regards,

Matthijs

On 7/8/26 10:28, Santiago Garcia Mantinan via bind-users wrote:
> Hi!
> 
> I've had similar problems running both Ubuntu's 9.18.39 and Debian's 9.20.23.
> 
> This comes after my first attempt at having a dnssec-policy to implement a
> zsk automatic rotation at 3 months using this policy:
> 
> dnssec-policy "rotate-zsk-3m" {
>      keys {
>          ksk key-directory lifetime unlimited algorithm 13;
>          zsk key-directory lifetime P3M algorithm 13;
>      };
>      nsec3param iterations 0 optout no salt-length 0;
> };
> 
> This had all timings by default and resulted on keys rotated at the very
> same time and the new one not being able to sign.  So I thought...  ok,
> maybe default timings were not right, maybe it was too fast, let's try to
> give us more time to check things, and I came out with this added parameters
> to the policy:
> 
>          dnskey-ttl 3600;
>          max-zone-ttl PT24H;
>          parent-ds-ttl P1D;
>          parent-propagation-delay 2h;
>          publish-safety 2d;
>          retire-safety PT1H;
>          signatures-jitter 12h;
>          signatures-refresh P5D;
>          signatures-validity P2W;
>          signatures-validity-dnskey P2W;
>          zone-propagation-delay 2h;
> 
> and we had an old 46658 key which was due to be retired in two days, on the
> 10th, so today, two days before the expiration days this is what happened...
> 
> zone --/IN (signed): reconfiguring zone keys
> keymgr: DNSKEY --/ECDSAP256SHA256/37202 (ZSK) created for policy rotate-zsk-3m
> Removing expired key --r/46658/ECDSAP256SHA256 from DNSKEY RRset.
> DNSKEY --/ECDSAP256SHA256/46658 (ZSK) is now deleted
> Fetching --/ECDSAP256SHA256/37202 (ZSK) from key repository.
> DNSKEY --/ECDSAP256SHA256/37202 (ZSK) is now published
> zone --/IN (signed): Key --/ECDSAP256SHA256/46658 missing or inactive and has no replacement: retaining signatures.
> 
> I can see why there is no replacement, the new key is still not valid, but
> why is the old one removed?
> 
> The resulting data for the old key right now is:
> 
> Generated: 20260408085815 (Wed Apr  8 10:58:15 2026)
> Published: 20260408085815 (Wed Apr  8 10:58:15 2026)
> Active: 20260408085815 (Wed Apr  8 10:58:15 2026)
> Retired: 20260710085815 (Fri Jul 10 10:58:15 2026)
> Removed: 20260722105815 (Wed Jul 22 12:58:15 2026)
> DNSKEYChange: 20260708055815 (Wed Jul  8 07:58:15 2026)
> ZRRSIGChange: 20260708055815 (Wed Jul  8 07:58:15 2026)
> DNSKEYState: unretentive
> ZRRSIGState: unretentive
> GoalState: hidden
> 
> and the new one says now ...
> 
> Generated: 20260708055815 (Wed Jul  8 07:58:15 2026)
> Published: 20260708055815 (Wed Jul  8 07:58:15 2026)
> Active: 20260710085815 (Fri Jul 10 10:58:15 2026)
> Retired: 20261011085815 (Sun Oct 11 10:58:15 2026)
> Removed: 20261021115815 (Wed Oct 21 13:58:15 2026)
> DNSKEYChange: 20260708055815 (Wed Jul  8 07:58:15 2026)
> ZRRSIGChange: 20260708055815 (Wed Jul  8 07:58:15 2026)
> DNSKEYState: rumoured
> ZRRSIGState: hidden
> GoalState: omnipresent
> 
> Good thing is that the new timings give me more time to see status of
> things, but... I just don't see how to make the new key active before the
> old one is removed, or at least at the same time.
> 
> What I saw, even though it says that old signatures are retained, is that
> after 7:58 I get no signatures on the hosts on the domain (they were signed
> before that time), the only signatures I see are the ones made with the ksk
> on the domain.
> 
> I hope someone can give some light on what is happening, as search results
> on google didn't show anything but old messages on the list which didn't
> match my problem.
> 
> Regards.



More information about the bind-users mailing list