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:
Hi Evilham,
thanks for using Knot DNS and for sharing your issues with us.
I was able to watch the misbehavoiur of your name server easily
with
kdig -t DNSKEY unchat.cat. @ns1.unchat.cat. +notcp
+cookie=deadbeefdeadbeef
I observed an infinite loop, caused by the server never being
happy with the
provided server cookie. Looking at the tcpdump, I saw that for
some queries, a
different server cookie was returned than sent, and for some,
DOUBLE cookie
option appeared in the response, with different server cookies.
I immediately caught a suspicion that such thing can happen if
the cookie module
is applied twice. Indeed, I was able co create equally
malfunctioning setup by
configuring:
mod-cookies:
- id: default
badcookie-slip: 1
template:
- id: "default"
global-module: mod-cookies/default
zone:
- domain: "example.com."
module: mod-cookies/default
...where the cookies module is inserted once as global and once
as per-zone.
Isn't this also your case? The "relevant bits" of your
configuration don't
include zone section :-\
This also might potentionally be the reason why DNSViz failed on
your domain,
unable to reach the DNSKEY records.
Looking forward to solving this,
Libor
Dne 20.10.20 v 23:27 Evilham napsal(a):
mod-cookies:
- id: default
badcookie-slip: 1
mod-rrl:
- id: default
rate-limit: 200 # Requests per second
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
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
