Re: view problem

On Wed, 19 Oct 2016, Mark Andrews wrote: In message , Jay Ford writes: Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views (i.e., it unfortunatley doesn't allow forward references).

Re: view problem

In message , Jay Ford writes: > On Tue, 18 Oct 2016, Barry Margolin wrote: > > If there are zones that both sets of clients should see, you have to > > duplicate them in both views. Overlapping views don't do this > > automatically. > >

Re: BIND 9.11.0 RPZ performance issue

Hi Bob On Tue, Oct 18, 2016 at 03:26:00PM -0400, Bob Harold wrote: > On Tue, Oct 18, 2016 at 3:26 AM, Mukund Sivaraman wrote: > > > > > Firstly, RPZ in BIND 9.9 (vanilla) is broken, unmaintained and should > > not be used by anyone. If you know people using BIND 9.9 (vanilla) for

Re: acl

On 8 October 2016 at 09:57, Pol Hallen wrote: > 192.168.1/24 is not a valid netmask >> > > huh? > In linux and BSD I always use 192.168.1/24 (how shortcut of 192.168.1.0/24) > and so on... You're confusing network configuration with ACL syntax. Where you're using

Re: BIND 9.11.0 RPZ performance issue

On Tue, Oct 18, 2016 at 3:26 AM, Mukund Sivaraman wrote: > > Firstly, RPZ in BIND 9.9 (vanilla) is broken, unmaintained and should > not be used by anyone. If you know people using BIND 9.9 (vanilla) for > RPZ, please ask them to upgrade to 9.10 at least. RPZ in 9.9 > subscription

Re: view problem

On Tue, 18 Oct 2016, Barry Margolin wrote: If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views

Re: view problem

In article , Pol Hallen wrote: > > Please be aware that only one view is visible for any client. > > mhmh... > > how I can solve my problem? > > all clients need to access to my zones but mobile clients (don't have

Re: view problem

Please be aware that only one view is visible for any client. mhmh... how I can solve my problem? all clients need to access to my zones but mobile clients (don't have vpn client) needs to access to all zones exception vpn (but can use FQDN) any idea? thanks POl

RE: view problem

Pol, If your master server itself providing DNS service to clients, then you may try something like this, (Else you may use the same order and forwarder on your slave servers) // vpn view "vpn" { match-clients { acl1; }; forward only; forwarders { 127.0.0.1; };

Re: view problem

Please be aware that only one view is visible for any client. You have acl1 in both views indicating that you assume a host in acl1 can get info from both views - this is not possible. The list is searched from the top of the file and the first match, only the first, will be the DNS service

Re: BIND 9.11.0 RPZ performance issue

Hi Phil On Tue, Oct 18, 2016 at 09:15:45AM +0100, Phil Mayers wrote: > On 18/10/16 08:26, Mukund Sivaraman wrote: > > > We know that IXFR with RPZ policy zones (esp. this DBL zone) causes some > > trouble due to a less than desirable design / implementation of RPZ in > > BIND. We have a plan to

RE: view problem

View concept works in order, as you have internal_lan view first, acl1 users are falling to this view and not able to find vpn_zone. You may try swapping order, // vpn view "vpn" { match-clients { acl1; }; zone "vpn_zone" { type master; file

Re: BIND 9.11.0 RPZ performance issue

On 18/10/16 08:26, Mukund Sivaraman wrote: We know that IXFR with RPZ policy zones (esp. this DBL zone) causes some trouble due to a less than desirable design / implementation of RPZ in BIND. We have a plan to refactor the RPZ implementation for 9.12 to remove these inefficiencies. Can you

view problem

Hi all :-) I've two zones: zone1 is an internal zone and another zone: vpn. I need that acl1 can "see" internal vpn zone, the problem is that acl1 "see" vpn zone as external zone because this zone is a FQDN, while should see vpn as vpn.db. 192.168.1.0/24 are clients with also openvpn

Re: BIND 9.11.0 RPZ performance issue

Hi Daniel On Tue, Oct 18, 2016 at 09:08:37AM +0200, Daniel Stirnimann wrote: > It currently looks like that only having the spamhaus rpz zones active > causes the occasional timeouts. Maybe it's related to the zone size as > dbl.rpz.spamhaus.org is quite large. If i/o performance on the virtual >

Re: BIND 9.11.0 RPZ performance issue

>> I have upgraded some of our BIND resolvers from BIND 9.9.9-P3 to BIND >> 9.11.0 and I notice timeouts for 3 - 5 seconds about every 1 to 5 hour. > > Something to do with dlv.isc.org? No, I can rule out dlv.isc.org. It currently looks like that only having the spamhaus rpz zones active causes

RRL BIND Recursive

Hi,I have a few servers running a recursive DNS bind service, i configured one of the servers to limit the rate of requests.my configuration is:rate-limit { log-only yes; errors-per-second 8; nxdomains-per-second 8; ipv4-prefix-length 32;As soon as i apply these changes my server drop 90% of