Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

John, thanks for helping. > You might start things out by giving us your bind version 9.10.1-P1 > and your response-policy {} config. response-policy { zone "rpz-whitelist" policy given; zone "rpz-quarantine" policy given; zone "rpz-phish" policy given; z

Re: RPZ zone defined in a view

On 01/07/2015 02:31 PM, Mark Andrews wrote: > In message <54ad246d.7080...@redhat.com>, Tomas Hozza writes: > > Hello. > > > > The BIND ARM documentation in section 6.2.16.20 says that > > "Response policy zones are named in the response-policy > > option for the view or among the global options if

Re: RPZ zone defined in a view

In message <54ad246d.7080...@redhat.com>, Tomas Hozza writes: > Hello. > > The BIND ARM documentation in section 6.2.16.20 says that > "Response policy zones are named in the response-policy > option for the view or among the global options if there > is no response-policy option for the view." >

RPZ zone defined in a view

Hello. The BIND ARM documentation in section 6.2.16.20 says that "Response policy zones are named in the response-policy option for the view or among the global options if there is no response-policy option for the view." However named with the following configuration fails to start:

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

On 06/01/15 22:52, Anne Bennett wrote: I don't know what to make of this; it looks as though the technology is several years old, and my experience with ISC bind is usually excellent. Has anyone else encountered this type of flakiness? No, but we're not using client-ip RPZ, just qname-based b

Re: named assertion failure

On 06/01/2015 04:11, James Brown wrote: > Running BIND 9.10.1-P1 on Mac OS X 10.10.1. It’s been running fine - no > problems until this morning, when I got: > > > 06-Jan-2015 01:33:33.356 transfer of 'rpz.spamhaus.org/IN/external' > from 199.168.90.51#53: T