Re: [knot-dns-users] KSK Rollover - Lab Policy For Testing

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 >>>>>>> >