Hello!
I have a Knot 3.2.5 server running here which, for most zones, acts as a
bump-in-the-wire signer, and it's doing exactly what I expect it to do.
The same server carries a few secondary zones which are not signed, and I
notice that when Knot transfers these zones in, it doesn't NOTIFY its
secondaries, something which works fine for DNSSEC signed zones.
The following configuration is in place:
remote:
- id: pdns
address: 192.168.25.45@53
key: dsupload
block-notify-after-transfer: on # <-------
automatic-acl: on
template:
- id: default
zonefile-load: difference
file: "%s"
serial-policy: dateserial
master: pdns
catalog-role: member
catalog-zone: katz1
acl: [ xfr, notify_from_pdns, xfer_to_bind ]
notify: [ s1, s2, s3 ]
policy:
- id: manualHSM
manual: on
keystore: thales
cds-cdnskey-publish: rollover
ksk-submission: ds_checker
ds-push: pdns
zone:
- domain: sig.example
dnssec-policy: manualHSM
dnssec-signing: on
- domain: notsig.example
dnssec-signing: off
When sig.example is transferred in, Knot signs it, NOTIFYs its secondaries
(s1--s3), they XFR the zone and all's well.
When the unsigned notsig.example is transferred in, the logs indicate Knot is
seeing the new serial, and that's it; the secondaries are not NOTIFYd. (I can
manually `knotc notify', but that's not the point.)
Setting `block-notify-after-transfer: off' on the remote remediates this. Knot
then does NOTIFY its secondaries for the unsigned zone (and for the signed
zone).
The documentation states:
"When incoming AXFR/IXFR from this remote (as a primary server),
suppress sending NOTIFY messages to all configured secondary servers."
However, if I swich it off (i.e. enable notification), I do not see the NOTIFY
when knot initially transfers the unsigned zone which is then signed and hence
then notified.
Is this behavior expected, and have I interpreted it correctly?
Thanks & best regards,
-JP
I have a zone for which I'd like to ensure an admin cannot mistakenly kick off
a KSK rollover, so I am considering setting configuring its dnssec-policy to
one with `manual: on' which prevents even a `knotc zone-key-rollover' on it. I
have experimented with switching `manual: on' to `manual: off', and the idea
seems to work. I have also apparently successfully been able to alter
`ksk-lifetime', and have not noticed anything going wrong.
Based on this, I wish to know if it is considered safe to alter many (all?) of
a policy's settings, as long as neither algorithm nor key sizes are changed, and
whether it is safe to alter the policy itself (i.e. also change a policy
name for a zone).
ksk-lifetime, delays, rrsig-lifetimes, ksk-submission, etc.: can all these be
changed without breaking signing of a zone?
Thank you & regards,
-JP
Hello!
I have here a catalog zone with roughly 230 member zones in it, and I
occasionally see the following warning/error in the log:
2023-07-12T18:01:17+0200 warning: [k-catalog.] failed to update zone file (operation not permitted)
2023-07-12T18:01:17+0200 error: [k-catalog.] zone event 'flush' failed (operation not permitted)
The catalog itself appears to work correctly; it's transferred to secondary
BIND servers and they correctly process member zones.
template:
- id: default
storage: "..."
zonefile-load: difference
file: "%s"
serial-policy: dateserial
master: pdns
catalog-role: member
catalog-zone: k-catalog
acl: [ xfr, notify_from_pdns, xfer_to_bind ]
- id: catzonetemplate
catalog-role: generate
acl: xfer_to_bind
zone:
- domain: k-catalog
semantic-checks: off
template: catzonetemplate
journal-content: none
acl: [ xfr, xfer_to_bind ]
While pasting the configuration it occurs to me it might be due to there not
being a 'backing' file for the catalog. Is that the problem? Is it even
possible on a catalog-role:generate to have a file?
Thanks for your help.
-JP
Hi Knotty people,
I've started uprading my infrastructure to Debian 12 which comes with knot
3.2.6 (instead of 3.0.5) and since the upgrade my catalog zone
configuration doesn't seem to work anymore.
I have this in knot.conf:
zone:
- domain: dxld.catalog
catalog-role: interpret
catalog-template: dxld-master
template: dxld-master
dxld.catalog gets loaded properly, `knotc zone-read dxld.catalog`:
[dxld.catalog.] dxld.catalog. 0 SOA ns0.dxld.at. hostmaster.dxld.at. 2023070601 900 300 86400 300
[dxld.catalog.] version.dxld.catalog. 0 TXT "2"
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.at.
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.net.
[dxld.catalog.] zones.dxld.catalog. 0 PTR darkboxed.org.
but the zones pointed to don't get instantiated (as seen by `knotc
zone-status`). Any ideas what could have changed to break this?
Thanks,
--Daniel
Hey,
after an (unattended) upgrade to 3.2,7, one of my zones (the one that does
rapid KSK rollovers) failed to load. Trying ro reload emits these errors in
the log:
info: [83.204.91.in-addr.arpa.] zone file parsed, serial 1622013488
error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial
1622013488 -> 1686209286 (loop detected)
2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] failed to apply
journal changes, serial 1622013488 -> 1686209286 (loop detected)
warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected)
2023-06-23T12:11:57+0200 warning: [83.204.91.in-addr.arpa.] failed to load
journal (loop detected)
info: [83.204.91.in-addr.arpa.] zone not found
error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists)
2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] zone event 'load'
failed (not exists)
Calling `kjournalprint 83.204.91.in-addr.arpa` yields 600 lines of journal
full of both additions and deletions, nothing seems particularly wrong. Is
there anything I should try before purging the journal and starting from
scratch?
There are other zones on the same server with similar config that just work
normally, so I guess this is somehow related to the size of the journal for
this zone, which rotates DNSSEC keys very often.
--
Cheers,
Ondřej Caletka
The 3.0 documentation for catalog zones says the following:
«The difference is that standard DNS queries to a catalog zone are
answered with REFUSED as though the zone doesn’t exist, unless
querying over TCP from an address with transfers enabled by ACL.»
This seems like an odd requirement, and it breaks interoperability
with other vendors' authoritative servers. BIND, for example, does
not send the SOA check for a zone transfer over TCP, and so it's
impossible to use a Knot primary and BIND secondary with catalog
zones.
Is there some way to work around this?
