On 29/12/2025 11.10, Vladimír Čunát via knot-resolver-users wrote: I forgot this part.  In 6.x the main price will be CPU consumed when parsing the file.  (which is asynchronous if you do a reload)  And RAM to hold the resulting database.  We've been quite careful about performance impact on processing DNS requests.

Also I believe you are still not supporting zone transfers so I will still need to have the script download the RPZ and format it correctly. I wonder if you could improve the 6.x documentation by showing a sample RPZ zone file with all the supported actions, wildcards etc. Finally the rpz-ip match is something we tend to use heavily. I can turn those into "IP address renumbering" rules quite easily in my script. Are there limits to how many of those a server can support? Regards Francis From: Francis Turner Sent: Monday, December 29, 2025 8:20 PM To: 'Vladimír Čunát' &lt;vladimir.cunat(a)nic.cz&gt; Cc: Knot Resolver Users List &lt;knot-resolver-users(a)lists.nic.cz&gt; Subject: RE: [knot-resolver-users] Re: Introduction and questions about RPZ support Thank you for all your replies. It looks like I should be trying 6.x and recommended that our prospects and customers do too. That is extremely helpful Regards Francis From: Vladimír Čunát <vladimir.cunat@nic.cz<mailto:vladimir.cunat@nic.cz>> Sent: Monday, December 29, 2025 7:14 PM To: Francis Turner <francis@threatstop.com<mailto:francis@threatstop.com>> Cc: Knot Resolver Users List <knot-resolver-users@lists.nic.cz<mailto:knot-resolver-users@lists.nic.cz>> Subject: Re: [knot-resolver-users] Re: Introduction and questions about RPZ support On 29/12/2025 11.10, Vladimír Čunát via knot-resolver-users wrote: Also assuming it is supported, what are the performance impacts of large (say 500k+) RPZ policies? I forgot this part. In 6.x the main price will be CPU consumed when parsing the file. (which is asynchronous if you do a reload) And RAM to hold the resulting database. We've been quite careful about performance impact on processing DNS requests.

Ok now I've got some 6.x questions First how do you log RPZ hits successfully. I have following in my config.yaml local-data: rpz: - file: /tmp/xdns.rpz watchdog: true log: logging: level: info The rpz is blocking but I don't get anything in the log file The rsyslog conf is as follows - very simple because I thought I was missing things: if $syslogseverity-text == 'notice' or $syslogseverity-text == 'info' then /var/log/rpz/rpz.log I do see notifications that seem to be info level 2025-12-30T09:05:27.051743+00:00 knotresolver kresd[52353]: [taupd ] refreshing TA for . 2025-12-30T09:05:27.053046+00:00 knotresolver kresd[52351]: [taupd ] refreshing TA for . 2025-12-30T09:05:27.053093+00:00 knotresolver kresd[52353]: [tasign] signalling query triggered: _ta-4f66-9728. 2025-12-30T09:05:27.053119+00:00 knotresolver kresd[52351]: [tasign] signalling query triggered: _ta-4f66-9728. 2025-12-30T09:05:27.252034+00:00 knotresolver kresd[52353]: [tasign] signalling query triggered: _ta-4f66-9728. But there is no notice severity message when I get an RPZ block Relatedly the log: syntax in the documentation ( https://www.knot-resolver.cz/documentation/latest/config-local-data.html#cm… ) is not at all clear. It looks like I can leave it blank and get everything but if not what should it be? Second. Rpz-passthru appears not to be supported correctly If I have lines www.example.com. CNAME rpz-passthru. *.example.com. CNAME . Then www.example.com<http://www.example.com> should resolve while any other FQDN under example.com should not. In fact what seems to happen is www.example.com<http://www.example.com> is blocked too. I have played with swapping the order of the rules and it made no difference Finally, maybe a bug? The watchdog doesn't always trigger on an RPZ file change. Not quite sure what is the issue except that sed -i file.rpz definitely failed to trigger it. Regards Francis From: Vladimír Čunát &lt;vladimir.cunat(a)nic.cz&gt; Sent: Monday, December 29, 2025 9:24 PM To: Francis Turner &lt;francis(a)threatstop.com&gt; Cc: Knot Resolver Users List &lt;knot-resolver-users(a)lists.nic.cz&gt; Subject: Re: [knot-resolver-users] Re: Introduction and questions about RPZ support On 29/12/2025 12.34, Francis Turner wrote: Also I believe you are still not supporting zone transfers so I will still need to have the script download the RPZ and format it correctly. We don't, but the zone format is accepted, so you can go simple like kdig rpz.cesnet.cz AXFR @nsa.cesnet.cz > /tmp/cz.rpz Finally the rpz-ip match is something we tend to use heavily. I can turn those into "IP address renumbering" rules quite easily in my script. Are there limits to how many of those a server can support? That won't be practical at this point. These (legacy) renumbering rules are all passed for every record in the reply (in lua code). We do want to add efficient .rpz-ip support, but it's not there yet.

You asked for a use case for passthru There are a few that I can think of off the top of my head. The first is sanctions compliance. Some of our customers use us as a way to ensure that they are compliant with US/EU etc. sanctions on countries such as Libya. This means that they do not want to do business with any Libyan organization or entity and thus we give them a rule that blocks *.ly (and other rules that block the IP addresses in Libya, which is a whole separate issue) However there are a number of short url services that use the .ly ccTLD e.g. bit.ly, owl.ly. This means that we will normally have an RPZ policy where there is *.ly CNAME . bit.ly CNAME rpz-passthru. *.bit.ly CNAME rpz-passthru. owl.ly CNAME rpz-passthru. *.owl.ly CNAME rpz-passthru. etc. The second is dynamic DNS providers. Many dyn DNS providers are abused by cybercriminals who set up FQDNs under them that are malicious in one way or another. Again some of our customers have decided that it is safer for them to simply ban all dynamic DNS providers and explicitly whitelist the dyn DNS hostnames that their users need to go visit. Thus you might see a policy with *.duckdns.org CNAME garden.company.internal. somehomepage.duckdns.org CNAME rpz-passthru. The top level CNAME redirects to a walled garden where users can register that they want to visit a blocked dyn DNS domain. Then after IS approval the specific hostname is added as rpz-passthru There are some other similar usecases where organizations want to block most of the subdomains of a specific domain but allow access to a few. One example are the free developer domains provided by cloudflare, github and so on, such as ngrok.com or cloudflare’s pages.dev. As with dyn DNS because these domains are free, cyber criminals often use them to host, proxy or redirect to malicious content and thus there are significant security advantages in blocking all these services and explicitly whitelisting the specific hosts that users need to be able to visit. Another example is the use of DNS to block ads and trackers. Many tracker sites will give each customer their own subdomain. If a webpage you like is blocked because of the tracker code not loading then you can explicitly enable that tracker hostname and still block the majority of the junk for all other sites I hope that helps Regards Francis From: Vladimír Čunát &lt;vladimir.cunat(a)nic.cz&gt; Sent: Thursday, January 1, 2026 3:17 AM To: Francis Turner &lt;francis(a)threatstop.com&gt; Cc: Knot Resolver Users List &lt;knot-resolver-users(a)lists.nic.cz&gt; Subject: Re: [knot-resolver-users] Re: Introduction and questions about RPZ support On 30/12/2025 10.58, Francis Turner wrote: Relatedly the log: syntax in the documentation ( https://www.knot-resolver.cz/documentation/latest/config-local-data.html#cm… ) is not at all clear. It looks like I can leave it blank and get everything but if not what should it be? I suppose the documentation should have examples, and there aren't many variants so far anyway. You can't leave it blank. To get both you write e.g. log: [ name, ip ] Second. Rpz-passthru appears not to be supported correctly Correct. We don't support them yet. Our docs says: rules with rpz-* labels are ignored, e.g. .rpz-client-ip Perhaps, can you share more information about typical use cases that you have for these missing features? The thing is that the RPZ draft specifies very very complex mechanics how rules interact, and some of that would basically clash with what we have in Knot Resolver, so we don't follow all of that, but we certainly want to keep good support for use cases common in practice. https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-5 Also, beware that in our current implementation the rule *.example.com. CNAME . will return NXDOMAIN also for example.com itself, contrary to what RPZ definition says. Finally, maybe a bug? The watchdog doesn’t always trigger on an RPZ file change. Not quite sure what is the issue except that sed -i file.rpz definitely failed to trigger it. I can retest that later, but note that you need an extra dependency for the detection to work. https://repology.org/project/python:watchdog