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
Hello!
Knot 3.2.0 with a Thales HSM configured this way: (btw, I am not obfuscating
addresses or zone names -- these are actual testing names :)
keystore:
- id: thales
backend: pkcs11
config: "pkcs11:token=XX;pin-value=XXX /opt/nfast/toolkits/pkcs11/libcknfast.so"
key-label: on
policy:
- id: manualHSM
keystore: thales
single-type-signing: off
manual: on
zone:
- domain: tt05
dnssec-signing: on
dnssec-policy: manualHSM
master: pdns
acl: [ xfr, notify_from_pdns ]
The zone `tt05' exists on the primary and can be transferred, as the following
logs will show.
I start off by generating a KSK and a ZSK, and verify that the keys are
actually on the HSM:
$ keymgr tt05 generate algorithm=8 size=2048 ksk=yes zsk=no
579f877d1739efb7bcf551e41c8777e965f8416f
$ keymgr tt05 generate algorithm=8 size=2048 ksk=no zsk=yes
eb8ef53ebffbd9950bfa914f7f2b0f1cd43bbe63
$ cklist -n | grep tt05
CKA_LABEL "tt05. KSK"
CKA_LABEL "tt05. ZSK"
I now reload Knot, and at this point I am actually expecting the server to
"see" the new zone, get the keys, perform the transfer (XFR) and sign the zone.
But all that doesn't happen:
$ knotc reload
Reloaded
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:10:10+0100
2023-02-09T12:10:10+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:10:10+0100 error: [tt05.] zone event 'refresh' failed (not exists)
In the above, I don't understand why it's failed to load the keys. My
_assumption_ is that the server has enumerated the keys from the HSM but did
that before the two keys for this zone were created. Invoking `knotc
zone-keys-load' doesn't alter the situation.
I do understand the 'refresh' failing, as the zone tt05 doesn't as yet exist on
this knot secondary.
So I initiate a zone transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:11:04+0100 info: [tt05.] control, received command 'zone-retransfer'
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load keys (not exists)
2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:11:04+0100
2023-02-09T12:11:04+0100 error: [tt05.] refresh, failed (not exists)
2023-02-09T12:11:04+0100 error: [tt05.] zone event 'refresh' failed (not exists)
It is clear that the transfer succeeds (the logs on the primary corroborate
this), and knot apparently knows the correct keys to use for the zone.
Why is it not signing it?
$ knotc zone-sign tt05
OK
2023-02-09T12:11:38+0100 info: [tt05.] control, received command 'zone-sign'
2023-02-09T12:11:38+0100 info: [tt05.] DNSSEC, dropping previous signatures, re-signing zone
2023-02-09T12:11:38+0100 error: [tt05.] zone event 're-sign' failed (invalid parameter)
I now restart the server:
# <restart knotd>
2023-02-09T12:12:16+0100 info: Knot DNS 3.2.0 starting
2023-02-09T12:12:16+0100 info: loaded configuration file '/etc/knot.conf', mapsize 500 MiB
2023-02-09T12:12:16+0100 info: using UDP reuseport, incoming TCP Fast Open
2023-02-09T12:12:16+0100 info: binding to interface 10.24.34.16@5353
2023-02-09T12:12:16+0100 info: changed directory to /
2023-02-09T12:12:16+0100 info: loading 7 zones
2023-02-09T12:12:16+0100 info: [tt05.] zone will be loaded
2023-02-09T12:12:16+0100 info: starting server
2023-02-09T12:12:18+0100 info: [tt05.] failed to parse zone file '/var/zones/tt05' (not exists)
Here again, I understand it cannot parse the zone, because the transfer hasn't
actually been comitted to disk.
So I manually transfer:
$ knotc zone-retransfer tt05
OK
2023-02-09T12:13:23+0100 info: [tt05.] control, received command 'zone-retransfer'
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started
2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, signing started
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, successfully signed
2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, next signing at 2023-02-23T11:13:24+0100
2023-02-09T12:13:23+0100 info: [tt05.] refresh, remote 192.168.33.31@53, zone updated, 0.44 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800 seconds
2023-02-09T12:13:23+0100 info: [tt05.] zone file updated, serial 2023010100
And now the zone is signed.
Is there some way to 'streamline' this? :-) Or am I just doing something wrong
or being too impatient?
Best regards,
-JP
