87472c54eb669c66353503caa0a386b1e95602de ksk=yes zsk=no tag=32875 algorithm=8 size=2048 public-only=no created=1551267572 pre-active=0 publish=1551430817 ready=1551430817 active=0 retire-active=0 retire=0 post-active=0 remove=0 Hmm, shouldn't it be "active=1"?

Is this parameter mandatory? ksk-submission: test_zone_sbm

Thanks a lot, Thomas

On 03.03.19 18:45, daniel.salzman(a)nic.cz wrote: > Hi Thomas, > > Have you submitted the initial KSK (it shouldn't be in the ready state)? > If it isn't submitted, no further rollover can happen. > > Try something like: > > policy: >  - id: test >    ksk-lifetime: 1200 >    zsk-lifetime: 600 >    propagation-delay: 0 >    dnskey-ttl: 60 > > And ensure the maximum TTL value in the zone is low. > > Best, > Daniel > > On 2019-03-03 17:26, Thomas wrote: >> Hi, >> >> we are testing knot at the moment and are struggling with the concept of >> automatic KSK rollovers. We are planning to fetch the current CDS for >> further automatic processing and try to figure out how to achieve a >> policy that performs KSK rollovers in a short period of time for testing >> purposes. Until now we have not seen any KSK rollovers and we are not >> sure why this is not happening. Can someone show me an example of a >> policy that schedules a KSK rollover within a very short period, let's >> say once a day? What policy parameters must be set? And what must be the >> zone's parameters in terms of TTL and SOA values (expire, refresh, etc)? >> >> >> Thanks a lot, >> Thomas

thanks for clarification. A "knotc zone-ksk-submitted xx.tld" did the trick and rollover is now processing. Yet, I don't fully understand why that manual intervention is necessary as Knot would be able to find out the state of the DS record by itself.

Will the "knotc zone-ksk-submitted" command still be necessary for the initial DS lookup when signing a new zone? Or is the "ksk-submission" statement sufficient in any case?

From the knot documentation:

Hello Daniel, we tried the described approach, and it worked fine for zones, that we already executed "knotc zone-ksk-submitted xx.tld" for. For freshly added zones however the "knotc zone-status xx.tld" returns a status that indicates that the parent DS query has not been scheduled:

[xx.tld.] role: master | serial: 1551549547 | transaction: none | freeze: no | load: not scheduled | refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: +19h26m42s | NSEC3 resalt: +27D2h42m39s | parent DS query: not scheduled Also our logs do not show any attempts of parent DS queries for the affected zone, only for the zones that we previously executed "zone-ksk-submitted" for. Right now we add the zone using a default template (which does not make use of DNSSEC), because not all of our zones should be signed right away and switch the template to a signed template for specific zones, that we actually want to sign. Here's an excerpt from our current config: remote: - id: local-resolver address: 192.168.1.2 submission: - id: resolver parent: local-resolver policy: - id: shared algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 zsk-lifetime: 1d ksk-lifetime: 2d ksk-shared: true ksk-submission: resolver nsec3: true template: - id: default storage: "/var/lib/knot" semantic-checks: on global-module: mod-stats master: primary notify: secondaries acl: [primary, secondaries] - id: signed dnssec-signing: on dnssec-policy: shared acl: [primary, secondaries] notify: secondaries Maybe we get something fundamentally wrong, but from our experience there is no DS scheduling without an initial manual intervention via "knotc zone-ksk-submitted xx.tld". Any hint would be appreciated! Thank a lot, Thomas Am 05.03.19 um 11:49 schrieb Daniel Stirnimann: > Hello Thomas, > > On 05.03.19 11:24, Thomas E. wrote: >> Will the "knotc zone-ksk-submitted" command still be necessary for >> the >> initial DS lookup when signing a new zone? Or is the "ksk-submission" >> statement sufficient in any case? > > The use of "ksk-submission" is sufficient. > > From the knot documentation: > "At this point new KSK has to be submitted to the parent zone. Knot > detects the updated parent’s DS record automatically (and waits for > additional period of the DS’s TTL before retiring the old key) if > parent > DS check is configured, otherwise the operator must confirm it > manually > with knotc zone-ksk-submitted" > https://www.knot-dns.cz/docs/2.7/singlehtml/ > > I've never used "knotc zone-ksk-submitted". Maybe it's useful if you > have a broken trust chain to your zone and in some scenario you might > want to tell knot to go ahead... > > Daniel >

Hi Daniel, we add the new zones configured with the "default" template. When a customer is requesting DNSSEC we move the zone to the "signed" template. Could that be the problem?

Best regards, Thomas On 05.03.19 19:32, daniel.salzman(a)nic.cz wrote:

Hi Thomas, I'm still not sure what goes wrong in your case. The setup looks good and when I try something similar, it works for me - the DS check is planned whenever I add a zone to "signed" policy. Could you please send us the logs of Knot? (Also shuffle with the configured log verbosity first, e.g. like: log:       - target: "stdout"         any: "info" ). Thanks much! Libor Dne 06.03.19 v 16:47 Daniel Salzman napsal(a): > Hi, > > On 3/5/19 10:14 PM, Thomas wrote: >> Hi Daniel, >> >> we add the new zones configured with the "default" template. When a >> customer is requesting DNSSEC we move the zone to the "signed" template. >> >> Could that be the problem? >> > It shouldn't be. But as you use shared key, it's possible there is a > bug in the code. > We will investigate your setup... > > Daniel > >> Best regards, >> Thomas >> >> On 05.03.19 19:32, daniel.salzman(a)nic.cz wrote: >>> Hello Thomas, >>> >>> On 2019-03-05 18:31, Thomas E. wrote: >>>> Hello Daniel, >>>> >>>> we tried the described approach, and it worked fine for zones, that we >>>> already executed "knotc zone-ksk-submitted xx.tld" for. >>>> >>>> For freshly added zones however the "knotc zone-status xx.tld" returns >>>> a status that indicates that the parent DS query has not been >>>> scheduled: >>>> >>> Are the freshly added zones configured with template 'signed'? >>> >>> Daniel >>> >>>> [xx.tld.] role: master | serial: 1551549547 | transaction: none | >>>> freeze: no | load: not scheduled | refresh: not scheduled | update: >>>> not scheduled | expiration: not scheduled | journal flush: not >>>> scheduled | notify: not scheduled | DNSSEC re-sign: +19h26m42s | NSEC3 >>>> resalt: +27D2h42m39s | parent DS query: not scheduled >>>> >>>> Also our logs do not show any attempts of parent DS queries for the >>>> affected zone, only for the zones that we previously executed >>>> "zone-ksk-submitted" for. >>>> >>>> Right now we add the zone using a default template (which does not >>>> make use of DNSSEC), because not all of our zones should be signed >>>> right away and switch the template to a signed template for specific >>>> zones, that we actually want to sign. >>>> >>>> Here's an excerpt from our current config: >>>> >>>> remote: >>>>    - id: local-resolver >>>>      address: 192.168.1.2 >>>> >>>> submission: >>>>    - id: resolver >>>>      parent: local-resolver >>>> >>>> policy: >>>>    - id: shared >>>>      algorithm: RSASHA256 >>>>      ksk-size: 2048 >>>>      zsk-size: 1024 >>>>      zsk-lifetime: 1d >>>>      ksk-lifetime: 2d >>>>      ksk-shared: true >>>>      ksk-submission: resolver >>>>      nsec3: true >>>> >>>> template: >>>>    - id: default >>>>      storage: "/var/lib/knot" >>>>      semantic-checks: on >>>>      global-module: mod-stats >>>>      master: primary >>>>      notify: secondaries >>>>      acl: [primary, secondaries] >>>> >>>>    - id: signed >>>>      dnssec-signing: on >>>>      dnssec-policy: shared >>>>      acl: [primary, secondaries] >>>>      notify: secondaries >>>> >>>> >>>> Maybe we get something fundamentally wrong, but from our experience >>>> there is no DS scheduling without an initial manual intervention via >>>> "knotc zone-ksk-submitted xx.tld". >>>> >>>> Any hint would be appreciated! >>>> >>>> Thank a lot, >>>> Thomas >>>> >>>> >>>> >>>> >>>> Am 05.03.19 um 11:49 schrieb Daniel Stirnimann: >>>>> Hello Thomas, >>>>> >>>>> On 05.03.19 11:24, Thomas E. wrote: >>>>>> Will the "knotc zone-ksk-submitted" command still be necessary >>>>>> for the >>>>>> initial DS lookup when signing a new zone? Or is the >>>>>> "ksk-submission" >>>>>> statement sufficient in any case? >>>>> The use of "ksk-submission" is sufficient. >>>>> >>>>>   From the knot documentation: >>>>> "At this point new KSK has to be submitted to the parent zone. Knot >>>>> detects the updated parent’s DS record automatically (and waits for >>>>> additional period of the DS’s TTL before retiring the old key) if >>>>> parent >>>>> DS check is configured, otherwise the operator must confirm it >>>>> manually >>>>> with knotc zone-ksk-submitted" >>>>> https://www.knot-dns.cz/docs/2.7/singlehtml/ >>>>> >>>>> I've never used "knotc zone-ksk-submitted". Maybe it's useful if you >>>>> have a broken trust chain to your zone and in some scenario you might >>>>> want to tell knot to go ahead... >>>>> >>>>> Daniel >>>>>

Hi Thomas, Please, are you able to test Knot DNS 2.8.0? I think that this issue could already be fixed along with the improvement "DS check event is re-planned according to KASP even when purged timers". Thanks, Daniel On 3/7/19 5:09 PM, Thomas E. wrote: > Hi Libor, > > sorry for taking so long to come back to you, but we tried our best to trace down our previous steps to make this issue reproducible. > > We found out, that the described behavior does not affect all of the domains that we wanted to sign. We made this assumption based on a small set of domains that we used to test real-world DNSSEC integration with and that we frequently enabled and disabled signing for over and over again, while we were figuring out how we can use knot. > > To clarify this point: New domains, that have not been signed previously are not affected by this! > > The steps to reproduce the described problem are: > > 1. Set up a knot 2.7.6 using a config without (!) a submission section > 2. Add an unsigned zone to the config file and reload knot > 3. Set the template of the zone to "signed" and reload knot > 4. Execute "knotc zone-status" for the domain, and you should be able to observe the following state: "parent DS query: not scheduled" > 5. Set the template of the zone to make it unsigned again and reload knot > 6. Add the submission section to the knot.conf and reload knot > 7. Set the template of the zone to "signed" and reload knot > 8. Execute "knotc zone-status" for the domain, and you should be able to still observe the following state: "parent DS query: not scheduled" > > This seems to indicate that there is some persistent state, that remains for the zones that have been removed from the signed template, and that this state actually prevents the parent DS query from being scheduled (ever?) again. > > I hope that this description gives you enough insight to evaluate the behavior. > > Best regards, > Thomas > > Am 06.03.19 um 18:03 schrieb libor.peltan: >> Hi Thomas, >> >> I'm still not sure what goes wrong in your case. The setup looks good and when I try something similar, it works for me - the DS check is planned whenever I add a zone to "signed" policy. >> >> Could you please send us the logs of Knot? (Also shuffle with the configured log verbosity first, e.g. like: >> >> log: >>        - target: "stdout" >>          any: "info" >> >> ). Thanks much! >> >> Libor >> >> Dne 06.03.19 v 16:47 Daniel Salzman napsal(a): >>> Hi, >>> >>> On 3/5/19 10:14 PM, Thomas wrote: >>>> Hi Daniel, >>>> >>>> we add the new zones configured with the "default" template. When a >>>> customer is requesting DNSSEC we move the zone to the "signed" template. >>>> >>>> Could that be the problem? >>>> >>> It shouldn't be. But as you use shared key, it's possible there is a bug in the code. >>> We will investigate your setup... >>> >>> Daniel >>> >>>> Best regards, >>>> Thomas >>>> >>>> On 05.03.19 19:32, daniel.salzman(a)nic.cz wrote: >>>>> Hello Thomas, >>>>> >>>>> On 2019-03-05 18:31, Thomas E. wrote: >>>>>> Hello Daniel, >>>>>> >>>>>> we tried the described approach, and it worked fine for zones, that we >>>>>> already executed "knotc zone-ksk-submitted xx.tld" for. >>>>>> >>>>>> For freshly added zones however the "knotc zone-status xx.tld" returns >>>>>> a status that indicates that the parent DS query has not been >>>>>> scheduled: >>>>>> >>>>> Are the freshly added zones configured with template 'signed'? >>>>> >>>>> Daniel >>>>> >>>>>> [xx.tld.] role: master | serial: 1551549547 | transaction: none | >>>>>> freeze: no | load: not scheduled | refresh: not scheduled | update: >>>>>> not scheduled | expiration: not scheduled | journal flush: not >>>>>> scheduled | notify: not scheduled | DNSSEC re-sign: +19h26m42s | NSEC3 >>>>>> resalt: +27D2h42m39s | parent DS query: not scheduled >>>>>> >>>>>> Also our logs do not show any attempts of parent DS queries for the >>>>>> affected zone, only for the zones that we previously executed >>>>>> "zone-ksk-submitted" for. >>>>>> >>>>>> Right now we add the zone using a default template (which does not >>>>>> make use of DNSSEC), because not all of our zones should be signed >>>>>> right away and switch the template to a signed template for specific >>>>>> zones, that we actually want to sign. >>>>>> >>>>>> Here's an excerpt from our current config: >>>>>> >>>>>> remote: >>>>>>    - id: local-resolver >>>>>>      address: 192.168.1.2 >>>>>> >>>>>> submission: >>>>>>    - id: resolver >>>>>>      parent: local-resolver >>>>>> >>>>>> policy: >>>>>>    - id: shared >>>>>>      algorithm: RSASHA256 >>>>>>      ksk-size: 2048 >>>>>>      zsk-size: 1024 >>>>>>      zsk-lifetime: 1d >>>>>>      ksk-lifetime: 2d >>>>>>      ksk-shared: true >>>>>>      ksk-submission: resolver >>>>>>      nsec3: true >>>>>> >>>>>> template: >>>>>>    - id: default >>>>>>      storage: "/var/lib/knot" >>>>>>      semantic-checks: on >>>>>>      global-module: mod-stats >>>>>>      master: primary >>>>>>      notify: secondaries >>>>>>      acl: [primary, secondaries] >>>>>> >>>>>>    - id: signed >>>>>>      dnssec-signing: on >>>>>>      dnssec-policy: shared >>>>>>      acl: [primary, secondaries] >>>>>>      notify: secondaries >>>>>> >>>>>> >>>>>> Maybe we get something fundamentally wrong, but from our experience >>>>>> there is no DS scheduling without an initial manual intervention via >>>>>> "knotc zone-ksk-submitted xx.tld". >>>>>> >>>>>> Any hint would be appreciated! >>>>>> >>>>>> Thank a lot, >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Am 05.03.19 um 11:49 schrieb Daniel Stirnimann: >>>>>>> Hello Thomas, >>>>>>> >>>>>>> On 05.03.19 11:24, Thomas E. wrote: >>>>>>>> Will the "knotc zone-ksk-submitted" command still be necessary for the >>>>>>>> initial DS lookup when signing a new zone? Or is the "ksk-submission" >>>>>>>> statement sufficient in any case? >>>>>>> The use of "ksk-submission" is sufficient. >>>>>>> >>>>>>>   From the knot documentation: >>>>>>> "At this point new KSK has to be submitted to the parent zone. Knot >>>>>>> detects the updated parent’s DS record automatically (and waits for >>>>>>> additional period of the DS’s TTL before retiring the old key) if parent >>>>>>> DS check is configured, otherwise the operator must confirm it manually >>>>>>> with knotc zone-ksk-submitted" >>>>>>> https://www.knot-dns.cz/docs/2.7/singlehtml/ >>>>>>> >>>>>>> I've never used "knotc zone-ksk-submitted". Maybe it's useful if you >>>>>>> have a broken trust chain to your zone and in some scenario you might >>>>>>> want to tell knot to go ahead... >>>>>>> >>>>>>> Daniel >>>>>>> >

Hi Thomas, just to make sure, with 2.8.0, it works like following? Configuration: zone has a policy assigned with submission configured with some remotes. (The configuration might have been different before and changed since in any way.) Cold start of Knot 2.8.0. It shows the line "KSK submission, waiting for confirmation" in the log. Still, there is no sign of DS checking activity and "parent DS query" is still "not planned" in "zone-status". ...right? I need to ensure because now it seems like a different malfunction, even though it might look the same for you ;) Thanks for clarification, Libor Dne 13.03.19 v 12:54 Thomas E. napsal(a): > Hi Daniel, > > we upgraded to 2.8.0 in the meantime. All I can say is that the > behavior is exactly the same. > The only difference we can see is that there is now one additional Log > Entry: > > "DNSSEC, KSK submission, waiting for confirmation" > > Best regards, > Thomas > > > Am 08.03.19 um 13:47 schrieb Daniel Salzman: >> Hi Thomas, >> >> Please, are you able to test Knot DNS 2.8.0? I think that this issue >> could already be fixed along >> with the improvement "DS check event is re-planned according to KASP >> even when purged timers". >> >> Thanks, >> Daniel >> >> On 3/7/19 5:09 PM, Thomas E. wrote: >>> Hi Libor, >>> >>> sorry for taking so long to come back to you, but we tried our best >>> to trace down our previous steps to make this issue reproducible. >>> >>> We found out, that the described behavior does not affect all of the >>> domains that we wanted to sign. We made this assumption based on a >>> small set of domains that we used to test real-world DNSSEC >>> integration with and that we frequently enabled and disabled signing >>> for over and over again, while we were figuring out how we can use >>> knot. >>> >>> To clarify this point: New domains, that have not been signed >>> previously are not affected by this! >>> >>> The steps to reproduce the described problem are: >>> >>> 1. Set up a knot 2.7.6 using a config without (!) a submission section >>> 2. Add an unsigned zone to the config file and reload knot >>> 3. Set the template of the zone to "signed" and reload knot >>> 4. Execute "knotc zone-status" for the domain, and you should be >>> able to observe the following state: "parent DS query: not scheduled" >>> 5. Set the template of the zone to make it unsigned again and reload >>> knot >>> 6. Add the submission section to the knot.conf and reload knot >>> 7. Set the template of the zone to "signed" and reload knot >>> 8. Execute "knotc zone-status" for the domain, and you should be >>> able to still observe the following state: "parent DS query: not >>> scheduled" >>> >>> This seems to indicate that there is some persistent state, that >>> remains for the zones that have been removed from the signed >>> template, and that this state actually prevents the parent DS query >>> from being scheduled (ever?) again. >>> >>> I hope that this description gives you enough insight to evaluate >>> the behavior. >>> >>> Best regards, >>> Thomas >>> >>> Am 06.03.19 um 18:03 schrieb libor.peltan: >>>> Hi Thomas, >>>> >>>> I'm still not sure what goes wrong in your case. The setup looks >>>> good and when I try something similar, it works for me - the DS >>>> check is planned whenever I add a zone to "signed" policy. >>>> >>>> Could you please send us the logs of Knot? (Also shuffle with the >>>> configured log verbosity first, e.g. like: >>>> >>>> log: >>>>         - target: "stdout" >>>>           any: "info" >>>> >>>> ). Thanks much! >>>> >>>> Libor >>>> >>>> Dne 06.03.19 v 16:47 Daniel Salzman napsal(a): >>>>> Hi, >>>>> >>>>> On 3/5/19 10:14 PM, Thomas wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> we add the new zones configured with the "default" template. When a >>>>>> customer is requesting DNSSEC we move the zone to the "signed" >>>>>> template. >>>>>> >>>>>> Could that be the problem? >>>>>> >>>>> It shouldn't be. But as you use shared key, it's possible there is >>>>> a bug in the code. >>>>> We will investigate your setup... >>>>> >>>>> Daniel >>>>> >>>>>> Best regards, >>>>>> Thomas >>>>>> >>>>>> On 05.03.19 19:32, daniel.salzman(a)nic.cz wrote: >>>>>>> Hello Thomas, >>>>>>> >>>>>>> On 2019-03-05 18:31, Thomas E. wrote: >>>>>>>> Hello Daniel, >>>>>>>> >>>>>>>> we tried the described approach, and it worked fine for zones, >>>>>>>> that we >>>>>>>> already executed "knotc zone-ksk-submitted xx.tld" for. >>>>>>>> >>>>>>>> For freshly added zones however the "knotc zone-status xx.tld" >>>>>>>> returns >>>>>>>> a status that indicates that the parent DS query has not been >>>>>>>> scheduled: >>>>>>>> >>>>>>> Are the freshly added zones configured with template 'signed'? >>>>>>> >>>>>>> Daniel >>>>>>> >>>>>>>> [xx.tld.] role: master | serial: 1551549547 | transaction: none | >>>>>>>> freeze: no | load: not scheduled | refresh: not scheduled | >>>>>>>> update: >>>>>>>> not scheduled | expiration: not scheduled | journal flush: not >>>>>>>> scheduled | notify: not scheduled | DNSSEC re-sign: +19h26m42s >>>>>>>> | NSEC3 >>>>>>>> resalt: +27D2h42m39s | parent DS query: not scheduled >>>>>>>> >>>>>>>> Also our logs do not show any attempts of parent DS queries for >>>>>>>> the >>>>>>>> affected zone, only for the zones that we previously executed >>>>>>>> "zone-ksk-submitted" for. >>>>>>>> >>>>>>>> Right now we add the zone using a default template (which does not >>>>>>>> make use of DNSSEC), because not all of our zones should be signed >>>>>>>> right away and switch the template to a signed template for >>>>>>>> specific >>>>>>>> zones, that we actually want to sign. >>>>>>>> >>>>>>>> Here's an excerpt from our current config: >>>>>>>> >>>>>>>> remote: >>>>>>>>     - id: local-resolver >>>>>>>>       address: 192.168.1.2 >>>>>>>> >>>>>>>> submission: >>>>>>>>     - id: resolver >>>>>>>>       parent: local-resolver >>>>>>>> >>>>>>>> policy: >>>>>>>>     - id: shared >>>>>>>>       algorithm: RSASHA256 >>>>>>>>       ksk-size: 2048 >>>>>>>>       zsk-size: 1024 >>>>>>>>       zsk-lifetime: 1d >>>>>>>>       ksk-lifetime: 2d >>>>>>>>       ksk-shared: true >>>>>>>>       ksk-submission: resolver >>>>>>>>       nsec3: true >>>>>>>> >>>>>>>> template: >>>>>>>>     - id: default >>>>>>>>       storage: "/var/lib/knot" >>>>>>>>       semantic-checks: on >>>>>>>>       global-module: mod-stats >>>>>>>>       master: primary >>>>>>>>       notify: secondaries >>>>>>>>       acl: [primary, secondaries] >>>>>>>> >>>>>>>>     - id: signed >>>>>>>>       dnssec-signing: on >>>>>>>>       dnssec-policy: shared >>>>>>>>       acl: [primary, secondaries] >>>>>>>>       notify: secondaries >>>>>>>> >>>>>>>> >>>>>>>> Maybe we get something fundamentally wrong, but from our >>>>>>>> experience >>>>>>>> there is no DS scheduling without an initial manual >>>>>>>> intervention via >>>>>>>> "knotc zone-ksk-submitted xx.tld". >>>>>>>> >>>>>>>> Any hint would be appreciated! >>>>>>>> >>>>>>>> Thank a lot, >>>>>>>> Thomas >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am 05.03.19 um 11:49 schrieb Daniel Stirnimann: >>>>>>>>> Hello Thomas, >>>>>>>>> >>>>>>>>> On 05.03.19 11:24, Thomas E. wrote: >>>>>>>>>> Will the "knotc zone-ksk-submitted" command still be >>>>>>>>>> necessary for the >>>>>>>>>> initial DS lookup when signing a new zone? Or is the >>>>>>>>>> "ksk-submission" >>>>>>>>>> statement sufficient in any case? >>>>>>>>> The use of "ksk-submission" is sufficient. >>>>>>>>> >>>>>>>>>    From the knot documentation: >>>>>>>>> "At this point new KSK has to be submitted to the parent zone. >>>>>>>>> Knot >>>>>>>>> detects the updated parent’s DS record automatically (and >>>>>>>>> waits for >>>>>>>>> additional period of the DS’s TTL before retiring the old key) >>>>>>>>> if parent >>>>>>>>> DS check is configured, otherwise the operator must confirm it >>>>>>>>> manually >>>>>>>>> with knotc zone-ksk-submitted" >>>>>>>>> https://www.knot-dns.cz/docs/2.7/singlehtml/ >>>>>>>>> >>>>>>>>> I've never used "knotc zone-ksk-submitted". Maybe it's useful >>>>>>>>> if you >>>>>>>>> have a broken trust chain to your zone and in some scenario >>>>>>>>> you might >>>>>>>>> want to tell knot to go ahead... >>>>>>>>> >>>>>>>>> Daniel >>>>>>>>> >>> >