On 4/8/23, Fred Morris <m3...@m3047.net> wrote:
> Since one of the corner cases where RPZ is used is for mitigation of
> failures of legitimate resources, I have a question...
>
> On Sat, 8 Apr 2023, Ondřej Surý wrote:
>> time.in is currently broken - I am guessing this is the reason why are you
>> trying to rewrite the answers.
>>
>> RPZ does try to resolve the name first, and it fails, so there’s nothing
>> to rewrite.
>
> Does this mean that in the default configuration an e.g. A record in an
> RPZ overriding brokenness in the global DNS with a QNAME override might
> fail due to the same brokenness? As far as I know I've never experienced
> that.
>
> Going forward, what is anticipated to be the proper configuration for that
> scenario?
I haven't noticed any problems with this bit:
response-policy { zone "thing1"; zone "thing2"; }
break-dnssec yes
recursive-only no
qname-wait-recurse no;
# enable rpz
# By default, RPZ actions are applied only to DNS requests that either do not
# request DNSSEC metadata (DO=0) or when no DNSSEC records are available for
# request name in the original zone (not the response policy zone).
# This default can be changed for all response policy zones in a view with a
# break-dnssec yes clause. In that case, RPZ actions are applied regardless
# of DNSSEC.
Regards,
Lee
--
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
