Hello :-)

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#response-policy-zones-rpz
(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