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

Hi, On 3/5/19 10:14 PM, Thomas wrote: 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 >>>>