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