24 Říj
2023
24 Říj
'23
8:33
Hi Robert!
The motivation for the change was a real issue encountered when a zone with a huge RRSet,
whose size before
compression exceeded 64k, was transferred to Knot DNS for signing. It worked well without
signing, but signing
of such a RRSet failed during preparation of raw data for RRSIG computation. The primary
implementation was PowerDNS,
but even Bind was able to load and send the zone. So we rather improved the
interoperability :-)
However, I agree that DNS processing at these limits is debatable. For example, it's
not possible to store
the maximum allowed RR in a DNS message already. Users of such data should be aware of
potential issues.
Daniel
On 10/23/23 23:10, Robert Edmonds wrote:
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!