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)
ond...@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@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)
>> ond...@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 <own3m...@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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
