February 1, 2021 11:07 AM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:
> On Mon, Feb 01, 2021 at 09:54:47AM +0000, pat...@patpro.net wrote: > >> 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. I do run BIND 9.16.x and I've just read a few things about dnssec-keymgr and dnssec-policy.conf that I need to dig in (https://www.sidn.nl/en/dnssec/dnssec-signatures-in-bind-named). > 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. It's a risk I can take if I'm stuck but I'm willing to try the dual-sign method. > 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. If I understand correctly CDNSKEY/CDS records allows full automation without requiring manually sending public keys to my registrar, is that correct? thanks patpro
