understanding keymgr handling of KSK

[Matthijs Mekking]

Hi,

On 09-05-2022 10:16, Bjørn Mork wrote:
> Michael Richardson via bind-users <bind-users at lists.isc.org> writes:
> 
>> 4) I don't understand the difference between "auto-dnssec maintain;"
>>     and "dnssec-policy default"  (given that I haven't overridden anything).
> 
> I believe the only difference is that the latter will track your keys in
> addition to the automatic signing.  And it will auto-generate CDS and
> CDNSKEY records.  None of which matters much until you start using it
> for automatic rollovers.

'auto-dnssec maintain' will also adjust the DNSSEC keys according to the 
key timing metadata ('auto-dnssec allow' will only update signatures).

'dnssec-policy' is also able to create new keys when needed and allows 
you to specify a policy for DNSSEC signing (roughly put: it moves 
dnssec-keymgr functionality inside BIND).


> I am not sure, but I suspect this is because the key didn't match your
> dnssec-policy.  So the rollover started immediately when you configured
> dnssec-policy, with a fresh KSK generatated and removal of the existing
> keys with "wrong" algorithms scheduled.

I suspect so too.

>> AFAIK, I'm not doing CDS (I'd like to, but I don't know how, and I don't know if .org is doing it).
> 
> Yes, same here.  This is not a problem. I learned from the discussion
> here earlier that BIND will just wait for me to manually tell if about
> the DS state using "rndc dnssec -checkds ...".  Which is fine.
> 
> What's surprising is that the KSK went missing without you telling BIND
> that the DS was removed.  I wonder if the problem is that it started out
> already having "DSState: hidden" because of the policy mismatch?

Yes, if BIND thinks the DS is not known to the world, it may remove the 
DNSKEY record.


- Matthijs