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, [email protected] 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 >>>>>>> > -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
