[knot-resolver-users] Re: Introduction and questions about RPZ support

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 <vladimir.cunat(a)nic.cz> Sent: Thursday, January 1, 2026 3:17 AM To: Francis Turner <francis(a)threatstop.com> Cc: Knot Resolver Users List <knot-resolver-users(a)lists.nic.cz> 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