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

Hello Thomas, On 2019-03-05 18:31, Thomas E. wrote: 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 >>