Daniel Salzman wrote:
> Hello Knot DNS users,
>
> CZ.NIC has released Knot DNS 3.3.2!
>
> This version fixes various issues and introduces some features regarding IXFR.
> Users of PKCS #11 keystore might appreciate improved signing performance using more thread.
>
> Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side!
>
> Changelog:
> https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS
Hi,
I'm interested in this change:
- knotd: failed to sign RRSet that fits to 64k only if compressed
Which seems to be this commit:
https://gitlab.nic.cz/knot/knot-dns/-/commit/f55037f6f39d0ddf6debac47fe168d…
"libknot/knot: allow uncompressed wire conversion of rrset that fits to
64k only when compressed"
It's not totally clear to me, but it seems like this would allow an
RRset (or individual RR, if the number of RRs in the RRset is 1?) that,
exceeds 64K, if name compression would reduce the size on the wire to
<64K? (And the 64K isn't measured by just the RDATA/RDLEN fields, but
rather the whole wire serialization of the record set, including owner
name, type, class, TTL, etc.)
If so, is this a safe and/or interoperable thing to do? DNS
implementations are required to implement decompression, but compression
is optional (RFC 1035 § 4.1.4). So a resolver might receive a compressed
RRset, decompress it, and then be unable to represent that RRset to
clients if it doesn't implement compression, or, more likely, implements
compression but uses an algorithm that generates less optimal
compression targets than the one used by the original nameserver.
Or am I misunderstanding what this commit is doing?
Thanks!
--
Robert Edmonds
edmonds(a)debian.org
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
