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.

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

Reply via email to