Re: [knot-dns-users] expiring/renewing dnssec keys

Hi dear knot users, Back again with a yet another question on the same subject. Hopefully this time the last one... We are a sub domain: sub.company.com, and in order to eanble DNSSEC, I need to enable DNSSEC on our knot zone sub.company.com, and send the DS key to company.com DNS admins for publication in the parent. My goal is to minimize the time between enabling DNSSEC and having our DS key published in the parent zone. As it turns out, is it incredibly difficult for company.com DNS admins to schedule a date/time to do this 'in sync' with us. The parent zone is now asking me to simply enable DNSSEC, and send them the DS keys. They will then submit a support request for that already active DS key to be published into the company.com DNS. Thing is: They are not sure how quickly that support request would be processed. So we could potentially face a significant amount of time (hours, days) of running knot with DNSSEC, without the DS key publised at the parent. (so basically: a broken chain of trust situation) My question: How disastrous (if at all) would that be? What consequences (if any) to expect? Or is there perhaps another approach at this that we fail to see? (other than asking company.com to change their dns hosting) (I was thinking perhaps: quickly enable dnssec, take note of the generated DS key, disable dnssec again, sent the DS key to parent, wait for it to become published, and then re-enable dnssec on knot) Enjoy your weekends everybody! MJ Op 31-08-2021 om 12:04 schreef mj: > ok, good to know! > > Thanks (again!) for the quick reply! > > MJ > > Op 31-08-2021 om 12:01 schreef Daniel Salzman: >> Hi, >> >> The extra white space is just a redundant separation of a long hex >> string. You can ignore it. >> >> Daniel >> >> On 8/31/21 11:49 AM, mj wrote: >>> Hi, >>> >>> We have a (hopefully last) follow-up question on the knot-generated >>> dnssec keys for our domain. >>> >>> Our policy is is set to algorithm: ECDSAP256SHA256. Upon knot >>> start, knot generates the  key: >>> >>>> knotd[25835]: info: [company.com.] DNSSEC, key, tag 54011, >>>> algorithm ECDSAP256SHA256, KSK, public, ready, active+ >>>> knotd[25835]: info: [company.com.] DNSSEC, key, tag 49404, >>>> algorithm ECDSAP256SHA256, public, active >>>> knotd[25835]: info: [company.com.] DNSSEC, signing started >>> >>> Then we query the DS key to be published, the result is: >>> >>>>   keymgr company.com ds >>>> company.com. DS 54011 13 2 >>>> f0892debae240caa01827becdd3d3cb0ef2512f5691ca525895777571a67e680 >>>> company.com. DS 54011 13 4 >>>> 462211ea3e8d3ea19a2ae803b926af8df851369527879911318f59ff72973a72452e3f29265c339c6a61537a778c43da >>>> >>> >>> >>> Now the question. In most (if not all?) docs we read on the >>> subject, the DS key looks something like: >>> >>>> knot-dns.cz.        3600    IN DS    54959 13 2 >>>> 268DE6EB7E0630953B8AF0F0037BF68FD10443BF01B5E17805AF94C2 6921897D >>> or >>>> dnssec-tools.org.    21600    IN DS    9638 13 2 >>>> 92551AA25C4ADE8E2882FBF4BEB5B54F9D84379B153848852B68BB3C 793F4B0B >>> >>> note the spaces at the end of the key string. >>> >>> Our knot-generated DS key does not have a space in it. >>> >>> Is something wrong? Do we need to add a space somewhere, or..? >>> >>> Thanks again in advance for providing insight :-) >>> >>> MJ