3 Feb
2026
3 Feb
'26
7:22 p.m.
Hi All,
Just wondering how you guys are ingesting RPZ feeds into Knot Resolver.
While Knot doesn't natively support zone transfers at this time, it
can import the zone files, and then kick the zone if the file changes,
so that's what I'm doing.
I'm doing the zone transfers (10 zones from ioc2rpz) using BIND for
now, and then writing the zone files to storage that Knot Resolver can
read.
I know that dns4eu uses Knot Resolver for their protective recursor
service, so I'd be curious to know how they're doing this.
Could be that they're using a custom version of Knot that's zone
transfer capable.
For context, I run Knot Resolver behind dnsdist, and they're
complimentary, offering huge flexibility.
Would be great to see rpz-passthru support in the BIND format too
(forgive me if that's already possible) so that a traditional
white-list-first tiered approach can be followed.
(Super impressed with Knot resolver, so hats off to all at CZ).
Cheers,
GC
4 Feb
4 Feb
9:23 a.m.
Hello.
On 03/02/2026 19.22, Giles Crawford wrote:
Just wondering how you guys are ingesting RPZ feeds
into Knot Resolver.
While Knot doesn't natively support zone transfers at this time, it
can import the zone files, and then kick the zone if the file changes,
so that's what I'm doing.
Some automation for obtaining RPZs is certainly among features which we
would like to add.
I'm doing the zone transfers (10 zones from
ioc2rpz) using BIND for
now, and then writing the zone files to storage that Knot Resolver can
read.
It's possible to
kdig @server AXFR zone.name > some file
or the same with dig or another tool. And run that on a timer.
Sometimes such a simplicity suffices, e.g. if the RPZ is small or
doesn't need to update often.
Would be great to see rpz-passthru support in the BIND
format too
(forgive me if that's already possible) so that a traditional
white-list-first tiered approach can be followed.
We have code for that outside the master branch and releases already,
but I'm not sure about details, i.e. what behavior is mostly expected on
conflicting rules, CNAMEs, etc. (I do know that the RPZ draft does
specify this, but...)
(Super impressed with Knot resolver, so hats off to
all at CZ).
Thanks :-)
--Vladimir
11:10 a.m.
Hi Vladimir,
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.
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.
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.
The issue is that kresd does not currently recognise "rpz-passthru" in
the RPZ zone files, according to logged errors.
The lack of published / ratified RFCs around RPZs hasn't helped ;-)
(For interested parties, ioc2rpz is worth a look, offering free
accounts, many zones, and the ability to zone transfer from their
primary servers.)
Cheers,
GC
On Wed, 4 Feb 2026 at 08:23, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
Hello.
On 03/02/2026 19.22, Giles Crawford wrote:
Just wondering how you guys are ingesting RPZ feeds into Knot Resolver.
While Knot doesn't natively support zone transfers at this time, it
can import the zone files, and then kick the zone if the file changes,
so that's what I'm doing.
Some automation for obtaining RPZs is certainly among features which we would like to
add.
I'm doing the zone transfers (10 zones from ioc2rpz) using BIND for
now, and then writing the zone files to storage that Knot Resolver can
read.
It's possible to
kdig @server AXFR zone.name > some file
or the same with dig or another tool. And run that on a timer. Sometimes such a
simplicity suffices, e.g. if the RPZ is small or doesn't need to update often.
Would be great to see rpz-passthru support in the BIND format too
(forgive me if that's already possible) so that a traditional
white-list-first tiered approach can be followed.
We have code for that outside the master branch and releases already, but I'm not
sure about details, i.e. what behavior is mostly expected on conflicting rules, CNAMEs,
etc. (I do know that the RPZ draft does specify this, but...)
(Super impressed with Knot resolver, so hats off to all at CZ).
Thanks :-)
--Vladimir
11:49 a.m.
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
1:37 p.m.
Thanks Vladimir,
I read your responses with interest :-)
I will take a look at kdig and attempt to reproduce the behaviour
experienced with dig.
On the zone transfers, if you ever add this functionality, the
resolver needs to answer SOA queries per RPZ zone, as ISPs need to
check zone freshness / consistency, comparing the serial numbers
across multiple platforms / servers in different regions / etc.
Thanks for explaining the current RPZ logic and compromise for use
with the version on the jezek-test branch.
I'll drop off for now, as I don't want to take up too much of your
time, but I've enjoyed our conversation.
For completeness, I'm pasting a commented version of my current
config, in case anyone's interested.
Cheers,
GC
user@knot:/etc/knot-resolver$ cat config.yaml
workers: 4
network:
tcp-pipeline: 100
address-renumbering:
# If DNS answer is %source%, change it to %dest%
# Works great but logically better under local-data:?
- source: x.x.x.x/32
destination: y.y.y.y
# Recurse on this interface
out-interface-v4: a.s.d.f
do-ipv4: true
do-ipv6: false
listen:
- interface: z.x.c.v@53
kind: dns
# DoH works really well
- interface: 192.168.123.122
port: 443
kind: doh2
proxy-protocol:
enable: true
allow:
- 192.168.0.0/16
- 10.0.0.0/8
- 172.16.0.0/12
logging:
level: info
# crit|err|warning|notice|info|debug
target: syslog
# Can target directory be specified?
dnstap:
enable: false
unix-socket: /tmp/dnstap.sock
# by default log is disabled for all
log-queries: true
log-responses: true
# Nice - Also possible to enable/disable this
# for general logging, without adjusting the
# logging level?
views:
- subnets: [192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8]
answer: allow
- subnets: [0.0.0.0/0]
answer: refused
# Tagging untested
cache:
storage: /var/cache/knot-resolver
size-max: 2G
# prefetch expiring/frequent records
prefetch:
expiring: true
prediction:
period: 48
window: 60m
prefill:
- origin: "."
url: https://www.internic.net/domain/root.zone
refresh-interval: 12h
ca-file: /etc/ssl/certs/ca-certificates.crt
options:
priming: true
rebinding-protection: true
time-jump-detection: false
# Prevent snooping on cache content
# refuse-no-rd: false
local-data:
# addresses:
# a1.example.com: 2001:db8::1
# a2.example.org: [ 192.0.2.2, 192.0.2.3, 2001:db8::4 ]
# addresses-files:
# - /etc/hosts
records: |
trump.com. CNAME berniesanders.com.
# This works really well :-)
# Have not tested other query types
# Warning. 6.X currently flattens all layers as single zone
# First rpz-passthru for a question passes traffic
# with no further RPZ processing
rpz:
- file: /var/cache/bind/whitelist.rpz
watchdog: auto
- file: /var/cache/bind/malicious.ioc2rpz
watchdog: auto
- file: /var/cache/bind/doh.ioc2rpz
watchdog: auto
- file: /var/cache/bind/blocklist-malicious.ioc2rpz
watchdog: auto
- file: /var/cache/bind/oisd-full.ioc2rpz
watchdog: auto
- file: /var/cache/bind/blox-malicious.ioc2rpz
watchdog: auto
- file: /var/cache/bind/urlhaus.ioc2rpz
watchdog: auto
- file: /var/cache/bind/bforeai.ioc2rpz
watchdog: auto
- file: /var/cache/bind/phishtank.ioc2rpz
watchdog: auto
- file: /var/cache/bind/hblock.ioc2rpz
watchdog: auto
- file: /var/cache/bind/dga.ioc2rpz
watchdog: auto
# Return nxdomain for an entire zone and set the TTL
# Again, this is great
rules:
- name:
- x.com.
subtree: nxdomain
ttl: 30d
forward:
# Local zones to ns1.local.lan
- subtree: local.lan
servers: [ x.x.x.x ]
options:
authoritative: true
dnssec: false
dnssec:
enable: false
negative-trust-anchors:
# disable validation for specific zone
- 123ex4mple321.zxc
#RPZ zones for ref - No 1 GB+ tiers here ;-)
user@knot:/var/cache/bind$ ls -lth $PWD/*rpz*
-rw-r--r-- 1 root root 21M Feb 4 11:40 /var/cache/bind/oisd-full.ioc2rpz
-rw-r--r-- 1 root root 43K Feb 4 11:01 /var/cache/bind/urlhaus.ioc2rpz
-rw-r--r-- 1 root root 3.4M Feb 4 10:07 /var/cache/bind/blox-malicious.ioc2rpz
-rw-r--r-- 1 root root 1.1M Feb 4 09:17 /var/cache/bind/phishtank.ioc2rpz
-rw-r--r-- 1 root root 836 Feb 4 09:17 /var/cache/bind/phishtank.ioc2rpz.jnl
-rw-r--r-- 1 root root 188K Feb 3 17:24 /var/cache/bind/bforeai.ioc2rpz
-rw-r--r-- 1 root root 158K Feb 3 17:18 /var/cache/bind/doh.ioc2rpz
-rw-r--r-- 1 root root 56M Feb 3 17:14 /var/cache/bind/dga.ioc2rpz
-rw-r--r-- 1 root root 40M Feb 3 17:04 /var/cache/bind/hblock.ioc2rpz
-rw-r--r-- 1 root root 148M Feb 3 16:53 /var/cache/bind/malicious.ioc2rpz
-rw-r--r-- 1 root root 94M Feb 3 16:50
/var/cache/bind/blocklist-malicious.ioc2rpz
On Wed, 4 Feb 2026 at 10:49, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
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
1:56 p.m.
Out of interest I looked into it. Just a few comments below.
On 04/02/2026 13.37, Giles Crawford wrote:
network:
address-renumbering:
# If DNS answer is %source%, change it to %dest%
# Works great but logically better under local-data:?
- source: x.x.x.x/32
destination: y.y.y.y
Right. Well, this also needs a better implementation and making .rpz-ip
rules fill that. It's on the heap of RPZ-related plans. This old
renumbering module just isn't efficient, as for each address in reply it
iterates over each (!) renumbering rule (in Lua).
logging:
level: info
# crit|err|warning|notice|info|debug
target: syslog
# Can target directory be specified?
dnstap:
enable: false
unix-socket: /tmp/dnstap.sock
# by default log is disabled for all
log-queries: true
log-responses: true
# Nice - Also possible to enable/disable this
# for general logging, without adjusting the
# logging level?
The syslog-like logging can only be done to syslog, stdout or stderr so
far, not files. You can see that e.g. in docs:
https://www.knot-resolver.cz/documentation/latest/config-logging-monitoring…
Some extra logging (to the configured target: syslog) can be done by the
old lua policies (entered via /lua/script into YAML); nothing ergonomic yet:
https://www.knot-resolver.cz/documentation/latest/dev/modules-policy.html#a…
222
days inactive
223
days old
knot-resolver-users@lists.nic.cz
5 comments
2 participants
participants (2)
-
Giles Crawford -
Vladimír Čunát