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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users