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
6 matches
Mail list logo
