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

[Matthijs Mekking]

Hi Magnus,

On 10-08-2022 11:13, Magnus Holmgren wrote:
> Hi,
> 
> I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and
> at the same time switched from auto-dnssec maintain to a dnssec-policy with
> RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the
> old keys and with unlimited lifetime to avoid confusing BIND).
> 
> Though it seems to take longer than expected to finish a key rollover, even
> taking into account propagation delay, TTLs, and retire-safety, the old keys
> were eventually removed from the first zone. One zone I'm still waiting for,
> and that rollover started Friday. One question: Is it necessary to use rndc
> dnssec -checkds or is that only meant as a backup, and named is supposed to
> query the parent for DS records automatically?

That depends if you have set up parental-agents. If not, then you need 
to run 'rndc dnssec -checkds'.


> 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.


The subject of the mail seems to indicate a different problem than the 
body, or am I missing something?


Best regards,

Matthijs