-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-08-10 at 09:47 +1000, Mark Andrews wrote:
> > On 10 Aug 2018, at 5:46 am, Jim Popovitch via bind-users > s...@lists.isc.org> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Is it possible to...
> >
> > 1) u
This is the error I am getting
/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'
On Fri, Aug 10, 2018 at 9:10 AM Blason R wrote:
> Hi there,
>
> Where it should appear? ARM says it should appear inl Global-section of
> response-policy which I tried but getting error.
>
Hi there,
Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
Well mine is bit different. I have RPZ and almost 40+ RPZ entries wall
gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are being
resolved by windows
Well this is valid when users are directly talking to RPZ servers. What if
there is one more resolver in between like Active Directory which itself
acts as a DNS server? In that case I believe you don't need to do that,
right?
On Fri, Aug 10, 2018 at 12:33 AM Grant Taylor via bind-users <
bind-use
> On 10 Aug 2018, at 5:46 am, Jim Popovitch via bind-users
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Is it possible to...
>
> 1) use text only zone files, and
>
> 2) keep serials identical between those zone files and what is
> published in DNS, and
That’s not even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Is it possible to...
1) use text only zone files, and
2) keep serials identical between those zone files and what is
published in DNS, and
3) automatically handle signatures when adding new RRs, and
4) not have any journal files.
Is all of that
On 08/06/2018 08:14 AM, Leroy Tennison wrote:
As previously posted, I just added a slave of a master for disaster
recovery and now need to know how to promote it should the master be
offline too long.
Please see the reply that I just sent for details about how I handled
this problem in the pa
On 08/06/2018 07:40 AM, Leroy Tennison wrote:
If there is already an ISC document I didn't find it, please provide
the URL.
I'm not aware of any such best practices type document. I too would be
interested in reading it is it exists.
I just added a slave of a master for disaster recovery an
On 08/09/2018 01:01 AM, Lee wrote:
yes, it works just fine
Good.
it does, so you have to flag your local zones as rpz-passthru. eg:
*.home.net CNAME rpz-passthru.
localhost CNAME rpz-passthru.
8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8
8.0.0.0.10.rp
On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
> For example this one.
>
> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
> 0351dag.com. (29)
> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
> 0/1/0 (102)
>
With RPZ, the name is looked up normally f
Is it a big?? I mean certain domains from my rpz feeds are properly getting
resolved while few are giving nxdomain though they appear in zone.
On Thu, Aug 9, 2018, 8:57 PM Sam Wilson wrote:
> On 2018-08-09 14:00:55 +, Blason R said:
>
> > For example this one.
> >
> > 18:59:26.905177 IP 192.
On 2018-08-09 14:00:55 +, Blason R said:
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)
$ dig 0351dag.com
; <<>> DiG 9.8.3-P1 <<>> 0351dag.c
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)
On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
> Hi Bind-Users,
>
> I would really appreciate if some
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since th
On 8/9/18, Grant Taylor via bind-users wrote:
> On 08/08/2018 10:02 PM, Blason R wrote:
>> Due to the architecture since I have my internal DNS RPZ built I wanted
>> my other internal DNS servers should send traffic to RPZ server and
>> then RPZ would resolve on behalf of client.
>
> Speaking of
16 matches
Mail list logo
