Hi MJ, Correct. One thing left is that you should tell Knot that the parent already has the correct DS. This can be achieved in two ways: 1) by calling `knotc zone-ksk-submitted` 2) by configuring the submission section, you enable Knot to find out itself. https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#dnssec-key-rollovers Again, you have several options: 1) read the Knot log file (it's not too cluttered usually) 2) use structured logging (see the end of already linked documentation chapter; this is mostly useful for scripting) 3) not configure ksk-lifetime (set to zero = infinity) and either never roll KSK at all, or trigger the roll manually as needed by calling `knotc zone-key-rollover ksk` This is difficult to say. Unless quantum-computing apocalypse arrives, it seems quite safe to use single KSK for several years. Wish you all the best, Libor

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: Then we query the DS key to be published, the result is: Now the question. In most (if not all?) docs we read on the subject, the DS key looks something like: or 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

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

Hi MJ, I assume that having a DNSSEC signed zone below an insecure delegation makes no harm (comparing to un-signed zone) at all for any (possibly long) period of time. So you can simply enable DNSSEC signing on your Knot now, and wait for the parent to employ your DS later. In the meantime, your zone shall work equally as if unsigned (i.e. insecure, but working). It would be broken the other way around, if the parent published some DS, but your zone be un-signed -- that situation would lead to Bogus and inaccessibility of your zone. BR, Libor Dne 24. 09. 21 v 13:14 mj napsal(a): > 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

at all. If you don't do that; likely the only trouble you're likely to incur will be with MXs (mail exchange) accepting mail from you.