6 Bře
2019
6 Bře
'19
16:47
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, 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
>>