Response Policy Zone returns servfail for time.in Trigger

Lee ler762 at gmail.com
Sun Apr 9 12:24:11 UTC 2023


On 4/8/23, Fred Morris <m3047 at 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


More information about the bind-users mailing list