> On Nov 28, 2022, at 3:12 PM, vom513 <vom...@gmail.com> wrote: > > Thanks for the reply and info… > > I would have thought the CDS would be published before the key went active. > I.e. there would be a period of TWO DS’es at the parent (I’m assuming the > parent supports CDS/CDNSKEY which mine (registrar) does). > > Since the new key goes active, CDS is published, and the old key is retired > at the same time - isn’t this going to cause a (lack of coverage/chain of > trust) problem ? I’m really trying to get to a point of a “one command” > rollover. I.e. no API, no uploading DS, etc. I guess I’ll see tonight when > it happens, but I can’t help but feel when the clock strikes I’m going to be > missing DS for the new key at the parent. >
Sorry to self reply… So it did “work” as you said Matthijs… I don’t think I necessarily need those timers (publish/retire-safety) that I tweaked. I’d rather use as many bind defaults as possible. I think a big part of my issue was misunderstanding “retired” status. I nuked everything clean and will try this again once everything settles down. Thanks for your patience with me and pointers. PS: My registrar says they check CDS/CDNSKEY once a day. Do you think that’s reasonable ? I certainly appreciate them being cognizant/careful of too much load on their systems with too many frequent checks, but a day seems long to me... -- 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