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?
Hi,
Yesterday we got hit by the per-zone journal becoming full [1]
As a result we're looking into how we can monitor the status to warn us
if we're near the journal limits, but I can't find a way to report the
currant journal usage (global and per-zone).
Any ideas?
[1] https://gitlab.nic.cz/knot/knot-dns/-/issues/842
Hi,
Just upgraded knot-resolver on ubuntu-22.04. It installs and runs but
shows that the socket is not where it thinks it is.
Socket is at /run/knot-resolver/control@1 but the new version is looking
for it at /run/knot-resolver/control/1
systemctl status is available here: https://pastebin.com/56g22e2a
Thanks for the great software!
Mike Wright
