- enable dnssec for the zone / reverse zone in knot.conf - restart knot - display the generated dnssec keys, using: (plus the reverse) - send the outputs of the above to the admins at company.com - after they have entered the keys in their dns, the world can check & verify our dnssec, and things are operational.

Question one: Is there some kind of notification mechanism in knot, that reminds us (through email for example) that a ksk is about to expire, and keys need to be renewed at company.com dns? I cannot find such a function. Does it not exist? Or do we misunderstand something? It seems to be so vital.

Question two: How unreasonable/insecure would it be to take a longer ksk lifetime than one year, let's say 10 years. With the idea that we can always manually renew keys earlier, in case we need to.

Feedback on the above is welcome. We have scheduled a maintenance moment next week with the admins on company.com to send them the keys and activate dnssec. Thanks in advance for any feedback/pointers you can provide. Best regards, MJ

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

keymgr company.com ds company.com. DS 54011 13 2 f0892debae240caa01827becdd3d3cb0ef2512f5691ca525895777571a67e680 company.com. DS 54011 13 4 462211ea3e8d3ea19a2ae803b926af8df851369527879911318f59ff72973a72452e3f29265c339c6a61537a778c43da

knot-dns.cz. 3600 IN DS 54959 13 2 268DE6EB7E0630953B8AF0F0037BF68FD10443BF01B5E17805AF94C2 6921897D

dnssec-tools.org. 21600 IN DS 9638 13 2 92551AA25C4ADE8E2882FBF4BEB5B54F9D84379B153848852B68BB3C 793F4B0B

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.

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.