Thanks for the suggestions, folks. Using views with RPZs just gets
problematic.
Sharing vs forwarding: forwarding seems cleaner and although there are
two copies of /BIND/ I don't know that that visibility really hurts
anything. Plus that potentially allows the "rear view" resolver to live
on a
On Thu, Nov 18, 2021 at 04:06:01PM -0800, Fred Morris wrote:
> Thanks for the encouragement folks, I forged ahead and I've got a
> different error now:
>
> "response-policy zone 'rpz1.m3047.net' for view standard is not a
> master or slave zone"
>
> That's the final denoument. There are
Thanks for the encouragement folks, I forged ahead and I've got a
different error now:
"response-policy zone 'rpz1.m3047.net' for view standard is not a
master or slave zone"
That's the final denoument. There are several intermediate steps, such
as moving all zone definitions into the
Look in to "match-destination" in a view, i.e.
acl abcd.anycast {
10.10.10.1;
};
view "abcd" {
match-clients {
any;
};
match-destinations {
abcd.anycast;
};
...
};
The response-policy definition (and associated zone)
Fred Morris wrote:
>
> Didn't see any reason that it had to be separate instances of BIND,
> thought maybe I could do it with views, but I've run into a couple of
> roadblocks:
>
> 1. listen-on isn't supported in views.
Right, listen-on is for the server as a whole.
To control which view is
match-destinations ?
---
>From an Android device, using BlueMail, which forces top-posting.
On 18 Nov 2021, 20:40, at 20:40, Fred Morris wrote:
>I wanted to provide enhanced recursive DNS to (internal) clients on an
>"opt in" basis, which is to say that clients could choose whether or
>not
I wanted to provide enhanced recursive DNS to (internal) clients on an
"opt in" basis, which is to say that clients could choose whether or not
to receive enhanced replies based on what they configured as their local
caching resolver. The enhanced services come in the form of a Response
Policy
7 matches
Mail list logo
