Re: [knot-dns-users] Inter-operability issues with other DNS Servers

That was a great pointer, thank you so much for looking into it and for providing both a hint and a command that reproduces the issue. Indeed it was being applied twice, not in the zones but in the templates: in the default template with global-module and then once again in the secondary / signed templates as a regular module: template: - id: default storage: "/var/db/knot/primary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" global-module: mod-cookies/default global-module: mod-rrl/default global-module: mod-stats - id: secondary storage: "/var/db/knot/secondary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats - id: signed storage: "/var/db/knot/primary" dnssec-signing: on zonefile-load: difference semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats These Knot DNS instances are managed and deployed in a fully automated fashion (including PTR zones for delegation from RIPE) based on https://cdi.st, if it is of interest to anyone I can look into finishing the documentation ^^. Here is the relevant change that appears to be fixing this issue: https://git.sr.ht/~evilham/cdist-evilham/commit/main (now the modules are only applied in the default template as global-modules) I would also consider this to be a documentation bug, or is it something to be solved somewhere else in Knot DNS? I have already created a user on gitlab.nic.cz; in case it's to be solved by documenting, I'd be happy to do that and open a Merge Request. Thank you again! -- Evilham On dc., oct. 21 2020, libor.peltan wrote: