4 Úno
2026
4 Úno
'26
11:49
On 04/02/2026 11.10, Giles Crawford wrote:
Believe it or not, I tried the 'zone transfer via
dig' route,
scheduling via cron :-)
6 5 * * * dig @X.X.X.X -y hmac-sha256:ioc2rpz.net-foo doh.ioc2rpz
AXFR > /etc/knot-resolver/doh.ioc2rpz
The files produced by dig don't follow the masterfile format, however,
so neither kresd nor named would load them without modification.
YMMV with kdig; haven't tried it as yet.
That's surprising me. I certainly did succeed in the past with kdig and
knot-resolver with some zones (relatively simple cases, no authentication).
Given current constraints, I found that it's more
elegant to take a
zone transfer using an authoritative server (speaking of which, I must
try the Knot one), which can then also better keep the zone fresh.
Kresd's excellent watch functionality for RPZs makes this possible.
Sure, I do consider using auth servers among the best approaches here
(even though it's not trivial to set up all).
For the RPZ stack logic to make sense in a top-down
approach, guessing
that we should make the decision / exist the stack on the first match,
so if passthru matches in tier 1 and there's an NXDOMAIN match in tier
2, the traffic gets passed.
I wasn't too keen on adding (many) tiers for efficiency reasons. So in
the currently released 6.x versions all local-data rules (+defaults) get
merged into a single tier, so a single search can search it all.
The issue is that kresd does not currently recognise
"rpz-passthru" in
the RPZ zone files, according to logged errors.
Yes. We do have this feature inside one public branch (jezek-test,
which gets used in a particular project now). The current semantics in
there is that if the QNAME in a client's request falls into a subtree of
any names in the allow-list (expressed by rpz-passthru), this whole
request's processing skips any blocking rules. It's a compromise,
nothing perfect, and it's unfortunately also far from the rpz-passthru
definition in the RPZ draft.
--Vladimir