Removing expired key when it is not yet retired

[Santiago Garcia Mantinan]

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?

Sorry for not being clear, we first implemented dnssec by setting dnssec-policy default
but we wanted to have separate KSK and ZSK, so we created the first basic
policy that I was mentioning:

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

and moved from default to it, everything went fine till we reached the 3
months, when key rollover was supposed to happen transparently we suffered
an outage as the signatures had disappeared and the new key was not signing.

To solve that we removed the signatures data and restarted for the zone to
be created again.

As we had this problem we thought that maybe things were too fast by
default, and setting parameters with longer times would help us control
things and give more time to see how it would transition, that's when we
added to that 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 thats when we saw that the old key was being removed while the new one
was still not valid so the domain lost again all of its signatures (exept
for the KSK ones) even though the messages say they are retained and they
where still valid.

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

I don't think this is bug, I'm thinking more on a missconfiguration on my
side, but I can't see where I may have gone wrong, that's why I was mailing
to ask if somebody with more experience on dnssec could spot something.

Thanks for your time.

Regards.

> 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.
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.

-- 
Manty/BestiaTester -> http://manty.net