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
