29 Pro
2025
29 Pro
'25
11:10
Hello :-)
On 29/12/2025 08.09, Francis Turner wrote:
The first is fairly basic. What is the status of 6.x?
From what I can see it seems to be undergoing development and not to
be considered as stable. Is this correct? And therefore we should not
recommend it to our users?
6.x is practically stable. This month in 6.0.17 we released last
planned incompatible changes, and if no blocker turns up very soon, we
will call it 6.1.0 as officially stable (promising backwards
compatibility during 6.1.x). For new deployments I certainly recommend
to start with 6.x. A few production deployments have been using it for
quite some time already.
Assuming that is the case, it’s unfortunate because
RPZ support seems
to be considerably better in 6.x. however I’m still a bit confused as
to the RPZ support and would appreciate being pointed to a spec. The
6.x documentation was not clear to me
There are a few bullets about the supported RPZ features (for 6.x) at
the end of the documentation section about RPZ:
https://www.knot-resolver.cz/documentation/latest/config-local-data.html#re…
(I corrected the wildcard bullet a few minutes ago)
Also I have questions about policy limitations, which
I don’t see in
the documentation for 5.x
How large can an RPZ be?
How many policies can you have?
For example I’d like an ALLOW, a DENY and perhaps one to three A
record rewrite policies. The total across all RPZs would be in the
500k-1M records.
Also assuming it is supported, what are the performance impacts of
large (say 500k+) RPZ policies?
I intend to test some of this, but if there are known limits that can
be shown that will help both the testing and the recommendations to
our customers
We impose no limits, but these things cost RAM+CPU. This holds for all
our versions.
Before 6.x the RPZ and other policy stuff weren't really designed to
handle really large rulesets, so I'd strongly suggest 6.x. Some
highlights for the relevant differences:
* in 6.x the database with rules is in memory shared among all
workers, so you don't pay extra for combining many rules with
multiple workers (i.e. multiple CPU threads)
* in 6.x the rules can be (re)loaded asynchronously with resolution;
in 5.x all resolving got paused during that and the work wasn't
shared among workers
Finally is there a place to publicize a script that
does a zone
transfer of a policy from an external server (e.g. ours) and outputs 3
or 4 zones in the right format for knot-resolver to import?
I'm not aware of anything like that so far. Perhaps let's start by
sending it to this mailing-list?
--Vladimir