Hi,
On 09-05-2022 10:16, Bjørn Mork wrote:
Michael Richardson via bind-users <bind-users@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
--
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
