dnssec-policy: Old DNSKEYs still in zone despite status showing hidden

[Magnus Holmgren]

torsdag 11 augusti 2022 kl. 17:41:09 CEST skrev  Matthijs Mekking:
> On 10-08-2022 11:21, Matthijs Mekking wrote:
> >> The last zone, milltime.se, has become stuck. sudo rndc dnssec -status
> >> reports
> >> that the old keys are removed from the zone and the new keys are
> >> omnipresent,
> >> but the log says "zone milltime.se/IN (signed): Key
> >> milltime.se/RSASHA1/22971
> >> missing or inactive and has no replacement: retaining signatures."
> >> 
> >> Never mind. I was too quick switching to NSEC3, which is incompatible
> >> with the
> >> old key. Switching back to NSEC allowed the rollover to complete. Still,
> >> shouldn't BIND have been able to figure this out on its own? It kept
> >> using
> >> NSEC because of the incompatible key, and it kept the incompatible key
> >> needed
> >> to verify the NSEC records. Catch-22? (Yes, I've read about the
> >> questionable
> >> merits of NSEC3.)
> > 
> > I think we could improve named-checkconf to error out on a policy that
> > uses NSEC3 with an incompatible algorithm yes. Thanks for the suggestion.
> 
> I jumped on this one too quickly. There is actually already a checkconf
> for this.
> 
> But your issue is slightly different. It is about configuring NSEC3 when
> the previous configuration uses an incompatible DNSKEY algorithm.
> 
> This is not easy to check with named-checkconf. But also, this is
> already caught by named.
> 
> You already witnessed some log messages indicating things are wrong: Key
> milltime.se/RSASHA1/22971 missing or inactive and has no replacement:
> retaining signatures." But perhaps you also saw this one: "zone
> milltime.se/IN (signed): NSEC only DNSKEYs and NSEC3 chains not allowed"
> which is more informative.
> 
> You recovered from this the right way: Switch back to using NSEC, until
> the old keys are gone from the zone, then you can enable NSEC3.
> 
> At first I thought BIND9 is handling this fine, but giving it another
> thought I think you are right that BIND could figure this out and rather
> than blocking signing because of the erroneous state, hold off creating
> NSEC3 chain until the offending DNSKEYs have been removed from the zone.

Exactly. I did notice the warning about NSEC only DNSKEYs already during 
testing, so I didn't immediately switch to NSEC3, but then I accidentally did 
it prematurely anyway, but I thought that BIND would act as if the nsec3param 
option simply didn't exist until the old keys had been removed, and I didn't 
immediately connect the two warnings together.

> So here is a merge request that you can try out, or you can wait until
> this makes a 9.18 release:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6647

Thanks. I'll see if I find time to test it, but right now the problem doesn't 
exist anymore.

-- 
Magnus Holmgren, developer
MILLNET AB