Significant memory usage

[Ondřej Surý]

Good point. As this is local setup, it makes much sense to use qname-wait-recurse no; this saves both
time and bandwidth as this is of no concern (from documentation):

> No DNS records are needed for a QNAME or Client-IP trigger; the name or IP address itself is sufficient, so in principle the query name need not be recursively resolved. However, not resolving the requested name can leak the fact that response policy rewriting is in use, and that the name is listed in a policy zone, to operators of servers for listed names. To prevent that information leak, by default any recursion needed for a request is done before any policy triggers are considered.

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 1. 7. 2025, at 21:34, Carlos Horowicz via bind-users <bind-users at lists.isc.org> wrote:
> 
> Ondřej,
> I usually include qname-wait-recurse no after the response-policy { ... } block, hoping to avoid issues where SERVFAILs, lame delegations, or firewalled authoritative servers might interfere with RPZ responses. I’m not entirely sure if I’m just being a bit superstitious about that — but I wanted to mention it in the context of the setup you described, which uses A and AAAA RRs (rather than CNAMEs or RPZ-SUFFIX rules). Perhaps qname-wait-recurse has a different impact in this case.
> I’ve always found it puzzling when a SERVFAIL appears in the logs just before a “CNAME .” redirection is applied, which makes me wonder if using A/AAAA redirection to 127.0.0.1 is ultimately more robust.
> Apologies if this adds noise to the thread — feel free to disregard if not relevant.
> Best regards,
> Carlos Horowicz
> Planisys
> 
> On 01/07/2025 21:00, Ondřej Surý wrote:
>> You'll have to experiment a bit (and I mean read the documentation[1]) as I am writing this from top of my head,
>> 
>> 1. You need to create RPZ zone like this:
>> 
>> $TTL 604800
>> $ORIGIN adaway.rpz.
>> @ IN SOA localhost. root.localhost. (1 604800 86400 2419200 604800 )
>> @ IN NS localhost.
>> ad-assets.futurecdn.net A 127.0.0.1
>> ad-assets.futurecdn.net AAAA ::1
>> [...]
>> 
>> I've used this command:
>> 
>> ( echo "@ IN SOA localhost. root.localhost. (1 604800 86400 2419200 604800 )"; echo "@ IN NS localhost." ; cat named_adaway.conf | cut -f 2 -d ' ' | while read D; do echo "$D IN A 127.0.0.1"; echo "$D IN AAAA ::1"; echo "*.$D IN A 127.0.0.1"; echo "*.$D IN AAAA ::1"; done ) > adaway.rpz.db
>> 
>> 2. Add the RPZ zone to your named.conf
>> 
>> zone adaway.rpz {
>> type primary;
>> file "/<PATH_TO>/adaway.rpz.db";
>> allow-query { localhost; };
>> };
>> 
>> 3. Add the response-policy to your options {} in named.conf
>> 
>> options {
>> [...]
>> response-policy { zone adaway.rpz; } break-dnssec yes;
>> [...]
>> };
>> 
>> And the memory usage on 9.20 is now mere 450MB:
>> PID User Command Swap USS PSS RSS
>> 514700 ondrej /home/ondrej/Projects/bind9 0 451684 452652 461872
>> 
>> $ dig +short -p 12345 @::1 ad-assets.futurecdn.net.
>> 127.0.0.1
>> $ dig +short -p 12345 @::1 foo.ad-assets.futurecdn.net.
>> 127.0.0.1
>> 
>> 1. https://bind9.readthedocs.io/en/v9.20.10/reference.html#response-policy-zone-rpz-rewriting
>> --
>> Ondřej Surý (He/Him)
>> ondrej at isc.org
>> 
>> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
>> 
>> 
>>> On 1. 7. 2025, at 20:40, OwN-3m-All <own3mall at gmail.com> wrote:
>>> 
>>> Also, 127.0.0.1 (localhost) needs to be returned for these hosts, not a NXDOMAIN response. Would that impact it?
>>> -- 
>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>> 
>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>> 
>> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users