On Mon, Feb 01, 2021 at 09:54:47AM +0000, pat...@patpro.net wrote:
> > but more importantly, your DNSSEC implementation is FUBAR:
>
> I've chosen to go with huge keys from the start to be "future proof",
> not so smart I guess.
Yes, turned out to just be a source of problems, with no benefit.
> What would be the main steps to renew keys with best practice in mind
> (algorithm 13 with ECDSA P256 keys)? I'm trying and find a good
> how-to but most are quite old and/or focus on initial setting only.
A lot depends on the software you're using for signing and serving your
zone. I highly recommend BIND 9.16, which has automated almost the
entire key management life-cycle, you just set up a policy and it
takes care of the rest. That's probably the best way forward if
your auth servers run BIND.
The easiest approach to not screw up is to remove your DS RRs for a
couple of days, then resign your zone, then add them back with the new
algorithm. If DNSSEC is not critical for you, go with that.
Otherwise, you'll need to dual-sign your zone, ideally delaying
the ZSK introduction until after all the new signatures are in
place (but this can be skipped with only modest short-term risk).
Then introduce the new ZSK and KSK into the DNSKEY RRset, (along
with the old) wait a few TTLs/days, and finally the new DS RRs.
The in reverse order, remove the old DS RRs, wait, the old KSK
and ZSK wait, and then the old RRSIGs (again perhaps combining
the ZSK and RRSIG removal). If that sounds too hard, consider
BIND 9.16 doing it all for you, or just going unsigned for a
couple of days.
And before you decide its all fixed for a few years, implement
*monitoring*. Unmonitored security is an oxymoron.
> I've ditched the ns6.gandi.net secondary DNS for now, will add it back
> later when my config will be "all green" again.
Already starting to look a bit better:
https://dnsviz.net/d/_25._tcp.mail.patpro.net/YBfQqw/dnssec/
--
Viktor.
