Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Blason R 
Ok got the issue and fixed it was long zone which was causing issue.

On Wed, Apr 25, 2018 at 10:28 AM, Blason R  wrote:

> Whoo..what is this all about guys? Is there any limit for zones?
>
>Active: active (running) since Wed 2018-04-25 10:25:27 IST; 2s ago
>  Docs: man:named(8)
>   Process: 4085 ExecStop=/usr/sbin/rndc stop (code=exited,
> status=0/SUCCESS)
>  Main PID: 4091 (named)
> Tasks: 7
>Memory: 146.1M
>   CPU: 1.527s
>CGroup: /system.slice/bind9.service
>└─4091 /usr/sbin/named -f -u bind
>
> Apr 25 10:25:27 dnsfw named[4091]: managed-keys-zone: loaded serial 13
> Apr 25 10:25:27 dnsfw named[4091]: zone 0.in-addr.arpa/IN: loaded serial 1
> Apr 25 10:25:27 dnsfw named[4091]: zone localhost/IN: loaded serial 2
> Apr 25 10:25:27 dnsfw named[4091]: zone 255.in-addr.arpa/IN: loaded serial
> 1
> Apr 25 10:25:27 dnsfw named[4091]: zone 127.in-addr.arpa/IN: loaded serial
> 1
> *Apr 25 10:25:28 dnsfw named[4091]: dns_master_load:
> /etc/bind/isnlab.in.db:345703: ran out of space*
> *Apr 25 10:25:28 dnsfw named[4091]: zone isnlab.in/IN
> : loading from master file /etc/bind/isnlab.in.db
> failed: ran out of space*
> *Apr 25 10:25:28 dnsfw named[4091]: zone isnlab.in/IN
> : not loaded due to errors.*
>
> *I have around 300+ zones*
>
> *root@dnsfw:/etc/bind# named -v*
> *BIND 9.10.3-P4-Ubuntu *
>
>
> On Wed, Apr 25, 2018 at 8:52 AM, Blason R  wrote:
>
>> Unfortunately neither RHEL nor CentOS gives RPM for 9.10+ and really
>> compiling and building is really pain and time consuming.
>> Hence I decided to give a try with Ubuntu 16.04 and any ways within few
>> days 18.04 is coming out with 9.11.
>>
>> BTW is 9.11 branch stable?
>>
>> On Wed, Apr 25, 2018 at 8:03 AM, Mukund Sivaraman  wrote:
>>
>>> On Tue, Apr 24, 2018 at 07:25:45PM -0700, Ray Van Dolson wrote:
>>> > On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
>>> > > On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
>>> > > > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
>>> > > > (Extended Support Version).
>>> > >
>>> > > RPZ in BIND 9.9 is experimental and unsupported (except for the
>>> > > subscription branch). Please use at least BIND 9.10 for RPZ.
>>> > >
>>> >
>>> > We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
>>> > (based on BIND 9.8.2).
>>> >
>>> > No issues.  Unsure if Red Hat backports the "more stable" code?
>>>
>>> I doubt it. But speaking for ISC BIND, 9.10+ is the only RPZ code we
>>> bugfix and there have been a lot of bugs fixed.
>>>
>>> Mukund
>>>
>>
>>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Blason R 
Whoo..what is this all about guys? Is there any limit for zones?

   Active: active (running) since Wed 2018-04-25 10:25:27 IST; 2s ago
 Docs: man:named(8)
  Process: 4085 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
 Main PID: 4091 (named)
Tasks: 7
   Memory: 146.1M
  CPU: 1.527s
   CGroup: /system.slice/bind9.service
   └─4091 /usr/sbin/named -f -u bind

Apr 25 10:25:27 dnsfw named[4091]: managed-keys-zone: loaded serial 13
Apr 25 10:25:27 dnsfw named[4091]: zone 0.in-addr.arpa/IN: loaded serial 1
Apr 25 10:25:27 dnsfw named[4091]: zone localhost/IN: loaded serial 2
Apr 25 10:25:27 dnsfw named[4091]: zone 255.in-addr.arpa/IN: loaded serial 1
Apr 25 10:25:27 dnsfw named[4091]: zone 127.in-addr.arpa/IN: loaded serial 1
*Apr 25 10:25:28 dnsfw named[4091]: dns_master_load:
/etc/bind/isnlab.in.db:345703: ran out of space*
*Apr 25 10:25:28 dnsfw named[4091]: zone isnlab.in/IN
: loading from master file /etc/bind/isnlab.in.db
failed: ran out of space*
*Apr 25 10:25:28 dnsfw named[4091]: zone isnlab.in/IN
: not loaded due to errors.*

*I have around 300+ zones*

*root@dnsfw:/etc/bind# named -v*
*BIND 9.10.3-P4-Ubuntu *


On Wed, Apr 25, 2018 at 8:52 AM, Blason R  wrote:

> Unfortunately neither RHEL nor CentOS gives RPM for 9.10+ and really
> compiling and building is really pain and time consuming.
> Hence I decided to give a try with Ubuntu 16.04 and any ways within few
> days 18.04 is coming out with 9.11.
>
> BTW is 9.11 branch stable?
>
> On Wed, Apr 25, 2018 at 8:03 AM, Mukund Sivaraman  wrote:
>
>> On Tue, Apr 24, 2018 at 07:25:45PM -0700, Ray Van Dolson wrote:
>> > On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
>> > > On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
>> > > > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
>> > > > (Extended Support Version).
>> > >
>> > > RPZ in BIND 9.9 is experimental and unsupported (except for the
>> > > subscription branch). Please use at least BIND 9.10 for RPZ.
>> > >
>> >
>> > We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
>> > (based on BIND 9.8.2).
>> >
>> > No issues.  Unsure if Red Hat backports the "more stable" code?
>>
>> I doubt it. But speaking for ISC BIND, 9.10+ is the only RPZ code we
>> bugfix and there have been a lot of bugs fixed.
>>
>> Mukund
>>
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Blason R 
Unfortunately neither RHEL nor CentOS gives RPM for 9.10+ and really
compiling and building is really pain and time consuming.
Hence I decided to give a try with Ubuntu 16.04 and any ways within few
days 18.04 is coming out with 9.11.

BTW is 9.11 branch stable?

On Wed, Apr 25, 2018 at 8:03 AM, Mukund Sivaraman  wrote:

> On Tue, Apr 24, 2018 at 07:25:45PM -0700, Ray Van Dolson wrote:
> > On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
> > > On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> > > > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> > > > (Extended Support Version).
> > >
> > > RPZ in BIND 9.9 is experimental and unsupported (except for the
> > > subscription branch). Please use at least BIND 9.10 for RPZ.
> > >
> >
> > We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
> > (based on BIND 9.8.2).
> >
> > No issues.  Unsure if Red Hat backports the "more stable" code?
>
> I doubt it. But speaking for ISC BIND, 9.10+ is the only RPZ code we
> bugfix and there have been a lot of bugs fixed.
>
> Mukund
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Mukund Sivaraman 
On Tue, Apr 24, 2018 at 07:25:45PM -0700, Ray Van Dolson wrote:
> On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
> > On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> > > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> > > (Extended Support Version).
> > 
> > RPZ in BIND 9.9 is experimental and unsupported (except for the
> > subscription branch). Please use at least BIND 9.10 for RPZ.
> > 
> 
> We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
> (based on BIND 9.8.2).
> 
> No issues.  Unsure if Red Hat backports the "more stable" code?

I doubt it. But speaking for ISC BIND, 9.10+ is the only RPZ code we
bugfix and there have been a lot of bugs fixed.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Ray Van Dolson 
On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
> On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> > (Extended Support Version).
> 
> RPZ in BIND 9.9 is experimental and unsupported (except for the
> subscription branch). Please use at least BIND 9.10 for RPZ.
> 
>   Mukund

We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
(based on BIND 9.8.2).

No issues.  Unsure if Red Hat backports the "more stable" code?

Ray
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Mukund Sivaraman 
On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> (Extended Support Version).

RPZ in BIND 9.9 is experimental and unsupported (except for the
subscription branch). Please use at least BIND 9.10 for RPZ.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Facing weird issue with DNS-RPZ

2018-04-24 Thread Bob Harold 
On Tue, Apr 24, 2018 at 8:33 AM, Blason R  wrote:

> Resending  since it seems it has few malicious domains
> -- Forwarded message --
> From: Blason R 
> Date: Tue, Apr 24, 2018 at 6:02 PM
> Subject: Facing weird issue with DNS-RPZ
> To: bind-users 
>
>
> Hello All,
>
> I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> (Extended Support Version).
>
> When I am manually creating writing a policy it works fine for CNAME while
> I have around 10k domains which needs to be wall-gardened but somehow as
> soon as I write simple while loop and entered in a .db file it stops RPZ
> functionality infact stops wall gardening instead it shows the real time.
>
> here is my zone config
>
> ###
>
> recursion yes;
> forwarders {1.1.1.1; 8.8.8.8; 9.9.9.9; };
> querylog yes;
> response-policy { zone "isnlab.in"; };
> check-names master ignore;
> check-names slave ignore;
>
> ###
>
> zone "isnlab.in" IN {
> type master;
> file "/var/named/firewall.local.db";
> };
>
>
> **
> $TTL 180
> @   IN  SOA ns1.isnlab.in. ns1.isnlab.in.(
> 2006060301  ; Serial
> 21600   ; Refresh
> 3600; Retry
> 604800  ; Expire
> 3600 )  ; Minimum TTL
>
> IN  NSns1.isnlab.in.
> ns1.isnlab.in.IN  A 172.16.3.46
> wg.isnlab.in.IN  A 172.16.3.46
> *.facebook.com  CNAME   wg.isnlab.in.
> facebook.comCNAME   wg.isnlab.in.
> testing.com CNAME   wg.isnlab.in.
> *.testing.com   CNAME   wg.isnlab.in.
> 000cas.info   CNAME   wg.isnlab.in.
> 000dfcc96tkpc.com CNAME   wg.isnlab.in.
>
> As soon as I add up the zones using below funcitonality it stops
> wallgardening and starts giving me real IPs
>
> This is before
> *$ dig @172.16.3.46  facebook.com
> *
>
> ; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6228
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;facebook.com.  IN  A
>
> *;; ANSWER SECTION:*
> *facebook.com .   5   IN  CNAME
>  wg.isnlab.in .*
> *wg.isnlab.in .   180 IN  A
>  172.16.3.46*
>
> *;; AUTHORITY SECTION:*
> *isnlab.in .  180 IN  NS
> ns1.isnlab.in .*
>
>
> 
> cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | while read
> line;do echo -e $line' \t ' CNAME' \t ' wg.isnlab.in.;done >>
> /var/named/firewall.local.db
>
> After this
> *$ dig @172.16.3.46  facebook.com
> *
>
> ; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32058
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;facebook.com.  IN  A
>
> ;; ANSWER SECTION:
> *facebook.com .   225 IN  A
>  157.240.13.35*
>
> ;; AUTHORITY SECTION:
> .   2972IN  NS  m.root-servers.net.
> .   2972IN  NS  a.root-servers.net.
> .   2972IN  NS  h.root-servers.net.
> .   2972IN  NS  j.root-servers.net.
> .   2972IN  NS  c.root-servers.net.
> .   2972IN  NS  i.root-servers.net.
> .   2972IN  NS  b.root-servers.net.
> .   2972IN  NS  g.root-servers.net.
> .   2972IN  NS  e.root-servers.net.
> .   2972IN  NS  k.root-servers.net.
> .   2972IN  NS  f.root-servers.net.
> .   2972IN  NS  d.root-servers.net.
> .   2972IN  NS  l.root-servers.net.
>
> ;; Query time: 128 msec
>
>
> Any clue why this is happening?
>

Check the logs for an error message saying that the zone failed to load,
and which line # had the error.

Also try this:
cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | egrep -v
'^[-0-9a-zA-Z.]*$'

There might be names that don't fit that pattern that are still ok, but it
is a start.

If not, then edit the zone and

Fwd: Facing weird issue with DNS-RPZ

2018-04-24 Thread Blason R 
Resending  since it seems it has few malicious domains
-- Forwarded message --
From: Blason R 
Date: Tue, Apr 24, 2018 at 6:02 PM
Subject: Facing weird issue with DNS-RPZ
To: bind-users 


Hello All,

I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2 (Extended
Support Version).

When I am manually creating writing a policy it works fine for CNAME while
I have around 10k domains which needs to be wall-gardened but somehow as
soon as I write simple while loop and entered in a .db file it stops RPZ
functionality infact stops wall gardening instead it shows the real time.

here is my zone config

###

recursion yes;
forwarders {1.1.1.1; 8.8.8.8; 9.9.9.9; };
querylog yes;
response-policy { zone "isnlab.in"; };
check-names master ignore;
check-names slave ignore;

###

zone "isnlab.in" IN {
type master;
file "/var/named/firewall.local.db";
};


**
$TTL 180
@   IN  SOA ns1.isnlab.in. ns1.isnlab.in.(
2006060301  ; Serial
21600   ; Refresh
3600; Retry
604800  ; Expire
3600 )  ; Minimum TTL

IN  NSns1.isnlab.in.
ns1.isnlab.in.IN  A 172.16.3.46
wg.isnlab.in.IN  A 172.16.3.46
*.facebook.com  CNAME   wg.isnlab.in.
facebook.comCNAME   wg.isnlab.in.
testing.com CNAME   wg.isnlab.in.
*.testing.com   CNAME   wg.isnlab.in.
000cas.info   CNAME   wg.isnlab.in.
000dfcc96tkpc.com CNAME   wg.isnlab.in.

As soon as I add up the zones using below funcitonality it stops
wallgardening and starts giving me real IPs

This is before
*$ dig @172.16.3.46  facebook.com *

; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6228
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.  IN  A

*;; ANSWER SECTION:*
*facebook.com .   5   IN  CNAME
 wg.isnlab.in .*
*wg.isnlab.in .   180 IN  A
 172.16.3.46*

*;; AUTHORITY SECTION:*
*isnlab.in .  180 IN  NS
ns1.isnlab.in .*



cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | while read
line;do echo -e $line' \t ' CNAME' \t ' wg.isnlab.in.;done >>
/var/named/firewall.local.db

After this
*$ dig @172.16.3.46  facebook.com *

; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.  IN  A

;; ANSWER SECTION:
*facebook.com .   225 IN  A
 157.240.13.35*

;; AUTHORITY SECTION:
.   2972IN  NS  m.root-servers.net.
.   2972IN  NS  a.root-servers.net.
.   2972IN  NS  h.root-servers.net.
.   2972IN  NS  j.root-servers.net.
.   2972IN  NS  c.root-servers.net.
.   2972IN  NS  i.root-servers.net.
.   2972IN  NS  b.root-servers.net.
.   2972IN  NS  g.root-servers.net.
.   2972IN  NS  e.root-servers.net.
.   2972IN  NS  k.root-servers.net.
.   2972IN  NS  f.root-servers.net.
.   2972IN  NS  d.root-servers.net.
.   2972IN  NS  l.root-servers.net.

;; Query time: 128 msec


Any clue why this is happening?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Upgrade from 9.9.11 to 9.11.3 on Windows 2012

2018-04-24 Thread Magnus Olofsson 
Our DNSSEC configuration settings:

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;





--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Upgrade from 9.9.11 to 9.11.3 on Windows 2012

2018-04-24 Thread Tony Finch 
Magnus Olofsson  wrote:

> Is there any mandatory change you have to make in the configuration?

You should be able to find the answer to this in the release notes.
I'm afraid I can't remember the details from that long ago :-)

> We got this warning in the log file:
> warning: managed-keys-zone: No DNSKEY RRSIGs found for '.': success

That suggests your server is forwarding via a resolver that doesn't do
DNSSEC. It's an old error message that's present in 9.9 so it's a bit
curious that you didn't see it before.

What are your DNSSEC configuration settings?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Southeast Iceland: Northerly in north, otherwise easterly or southeasterly, 5
or 6, becoming variable 4 later in north. Moderate, occasionally rough at
first in east and later in south. Rain or showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Upgrade from 9.9.11 to 9.11.3 on Windows 2012

2018-04-24 Thread Magnus Olofsson 
We are using BIND as a recursive resolver on a Windows 2012 server. After
upgrading from 9.9.11 to 9.11.3 we got some problem. In previous upgrades
there have been no problems. Is there any mandatory change you have to make
i the configuration?

We got this warning in the log file:
warning: managed-keys-zone: No DNSKEY RRSIGs found for '.': success




--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users