Re: also-notify and allow-notify

[Blason R]

Hi there,

Thanks for the update and here is my config and error I am getting. Can you
please suggest correct method that should be implemented?


**
zone "malware.trap" {
type master;
file "/var/lib/bind/zones/malware.trap.db";
notify explicit;
also-notify { 192.168.5.49; port ;};
allow-transfer {192.168.5.49; };
allow-query { localhost;};
};

zone "whitelist.allow" {
type master;
file "/var/lib/bind/zones/whitelist.allow";
notify explicit;
also-notify { 192.168.5.49; port ;};
allow-transfer {192.168.5.49; };
allow-query { localhost;};
};

zone "block.tld" {
type master;
file "/var/lib/bind/zones/block.tld.db";
notify explicit;
also-notify { 192.168.5.49; port ;};
allow-transfer {192.168.5.49; };
allow-query { localhost;};
};

**



May 18 13:04:42 dnsfw named[1134]: using up to 4096 sockets
May 18 13:04:45 dnsfw named[1134]: loading configuration from
'/etc/bind/named.conf'
*May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:34:
missing ';' before ''*
*May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:43:
missing ';' before ''*
*May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:52:
missing ';' before ''*
May 18 13:04:46 dnsfw systemd[1]: bind9.service: Main process exited,
code=exited, status=1/FAILURE
May 18 13:04:46 dnsfw rndc[1313]: rndc: connect failed: 127.0.0.1#953:
connection refused
May 18 13:04:46 dnsfw systemd[1]: bind9.service: Control process exited,
code=exited status=1


On Fri, May 18, 2018 at 12:08 AM, Matthew Pounsett 
wrote:

>
>
> On 17 May 2018 at 13:30, Blason R  wrote:
>
>> Hi,
>>
>> I have RPZ installed on server and its acting as a master server but
>> somehow port setting is not working on master
>>
>> [...]
>
>>
>> So here I am sending notification  to 192.168.5.49 on port 4545; my
>> queries are
>>
>> How do I configure port on slave 4545 so that slave server can start
>> listening on that port.
>>
>
> Your slave needs to be listening on the correct IP/port to receive the
> NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
> discussion on Interfaces starts at page 98.
>
>
>> And my master is failing  after restarting the services due to
>> notify-them statement.
>>
>
> You don't indicate what the error is, but I'm willing to bet it's the fact
> that you're trying to specify a masters list by name as well as a port.  If
> you look at the 'also-notify' statement definition, you can see that you're
> able to use a 'masters' list OR an IP address and port combination, but not
> both (ARM pp. 71).  You should specify the port number as part of the
> definition of the masters list, not where you use the masters list.
>
> [0]: 
>
>
>
___
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: also-notify and allow-notify

[Warren Kumari]

On Fri, May 18, 2018 at 9:41 AM Blason R  wrote:

> Hi there,

> Thanks for the update and here is my config and error I am getting. Can
you please suggest correct method that should be implemented?


I believe (but don't have a machine to confirm on) that the syntax should
be:

also-notify { 192.168.5.49 port ;};

(note the lack of semicolon between the IP and "port ")

W


> **
> zone "malware.trap" {
>  type master;
>  file "/var/lib/bind/zones/malware.trap.db";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> zone "whitelist.allow" {
>  type master;
>  file "/var/lib/bind/zones/whitelist.allow";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> zone "block.tld" {
>  type master;
>  file "/var/lib/bind/zones/block.tld.db";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> **



> May 18 13:04:42 dnsfw named[1134]: using up to 4096 sockets
> May 18 13:04:45 dnsfw named[1134]: loading configuration from
'/etc/bind/named.conf'
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:34:
missing ';' before ''
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:43:
missing ';' before ''
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:52:
missing ';' before ''
> May 18 13:04:46 dnsfw systemd[1]: bind9.service: Main process exited,
code=exited, status=1/FAILURE
> May 18 13:04:46 dnsfw rndc[1313]: rndc: connect failed: 127.0.0.1#953:
connection refused
> May 18 13:04:46 dnsfw systemd[1]: bind9.service: Control process exited,
code=exited status=1


> On Fri, May 18, 2018 at 12:08 AM, Matthew Pounsett 
wrote:



>> On 17 May 2018 at 13:30, Blason R  wrote:

>>> Hi,

>>> I have RPZ installed on server and its acting as a master server but
somehow port setting is not working on master

>> [...]


>>> So here I am sending notification  to 192.168.5.49 on port 4545; my
queries are

>>> How do I configure port on slave 4545 so that slave server can start
listening on that port.


>> Your slave needs to be listening on the correct IP/port to receive the
NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
discussion on Interfaces starts at page 98.


>>> And my master is failing  after restarting the services due to
notify-them statement.


>> You don't indicate what the error is, but I'm willing to bet it's the
fact that you're trying to specify a masters list by name as well as a
port.  If you look at the 'also-notify' statement definition, you can see
that you're able to use a 'masters' list OR an IP address and port
combination, but not both (ARM pp. 71).  You should specify the port number
as part of the definition of the masters list, not where you use the
masters list.

>> [0]: 



> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
___
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: also-notify and allow-notify

[Blason R]

Thats correct taht worked for me and checking further now.

On Fri, May 18, 2018 at 1:23 PM, Warren Kumari  wrote:

> On Fri, May 18, 2018 at 9:41 AM Blason R  wrote:
>
> > Hi there,
>
> > Thanks for the update and here is my config and error I am getting. Can
> you please suggest correct method that should be implemented?
>
>
> I believe (but don't have a machine to confirm on) that the syntax should
> be:
>
> also-notify { 192.168.5.49 port ;};
>
> (note the lack of semicolon between the IP and "port ")
>
> W
>
>
> > **
> > zone "malware.trap" {
> >  type master;
> >  file "/var/lib/bind/zones/malware.trap.db";
> >  notify explicit;
> >  also-notify { 192.168.5.49; port ;};
> >  allow-transfer {192.168.5.49; };
> >  allow-query { localhost;};
> >  };
>
> > zone "whitelist.allow" {
> >  type master;
> >  file "/var/lib/bind/zones/whitelist.allow";
> >  notify explicit;
> >  also-notify { 192.168.5.49; port ;};
> >  allow-transfer {192.168.5.49; };
> >  allow-query { localhost;};
> >  };
>
> > zone "block.tld" {
> >  type master;
> >  file "/var/lib/bind/zones/block.tld.db";
> >  notify explicit;
> >  also-notify { 192.168.5.49; port ;};
> >  allow-transfer {192.168.5.49; };
> >  allow-query { localhost;};
> >  };
>
> > **
>
>
>
> > May 18 13:04:42 dnsfw named[1134]: using up to 4096 sockets
> > May 18 13:04:45 dnsfw named[1134]: loading configuration from
> '/etc/bind/named.conf'
> > May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-
> zones:34:
> missing ';' before ''
> > May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-
> zones:43:
> missing ';' before ''
> > May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-
> zones:52:
> missing ';' before ''
> > May 18 13:04:46 dnsfw systemd[1]: bind9.service: Main process exited,
> code=exited, status=1/FAILURE
> > May 18 13:04:46 dnsfw rndc[1313]: rndc: connect failed: 127.0.0.1#953:
> connection refused
> > May 18 13:04:46 dnsfw systemd[1]: bind9.service: Control process exited,
> code=exited status=1
>
>
> > On Fri, May 18, 2018 at 12:08 AM, Matthew Pounsett 
> wrote:
>
>
>
> >> On 17 May 2018 at 13:30, Blason R  wrote:
>
> >>> Hi,
>
> >>> I have RPZ installed on server and its acting as a master server but
> somehow port setting is not working on master
>
> >> [...]
>
>
> >>> So here I am sending notification  to 192.168.5.49 on port 4545; my
> queries are
>
> >>> How do I configure port on slave 4545 so that slave server can start
> listening on that port.
>
>
> >> Your slave needs to be listening on the correct IP/port to receive the
> NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
> discussion on Interfaces starts at page 98.
>
>
> >>> And my master is failing  after restarting the services due to
> notify-them statement.
>
>
> >> You don't indicate what the error is, but I'm willing to bet it's the
> fact that you're trying to specify a masters list by name as well as a
> port.  If you look at the 'also-notify' statement definition, you can see
> that you're able to use a 'masters' list OR an IP address and port
> combination, but not both (ARM pp. 71).  You should specify the port number
> as part of the definition of the masters list, not where you use the
> masters list.
>
> >> [0]: 
>
>
>
> > ___
> > 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
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
> ---maf
>
___
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: also-notify and allow-notify

[Matus UHLAR - fantomas]

On 17.05.18 23:00, Blason R wrote:

I have RPZ installed on server and its acting as a master server but
somehow port setting is not working on master



# Slave configuration

response-policy { zone "malware.trap"; };

zone "malware.trap" {
 type slave;
 masters { 192.168.5.48; };
  file "/var/lib/bind/malware.trap.db";
 allow-notify { 192.168.5.48; };


this is superflous. The default is to accept notifies from master.


 allow-query {localhost; };
};


So here I am sending notification  to 192.168.5.49 on port 4545; my queries
are



  1. How do I configure port on slave 4545 so that slave server can start
  listening on that port.


why do you need to listen on port 4545 instead of default 53?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
We are but packets in the Internet of life (userfriendly.org)
___
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: Intermittent "failure trying master... operation canceled" on zone refresh

[Tony Finch]

Rob Moser  wrote:
>
> Which a little digging shows me is often the result of network
> connectivity problems, firewall misconfigurations, etc.  But in our case
> the failures are intermittent (but frequent; roughly 40% of our zone
> refreshes seem to end this way.)

Have you made sure there is no connection tracking / stateful packet
filtering configured on port 53?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Westerly 6 to gale 8, backing southerly ot southeasterly 5
to 7, perhaps gale 8 later. Rough occasionally very rough. Showers, rain
later. Moderate or good, becoming poor later.
___
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: also-notify and allow-notify

[Blason R]

Nah that is not my query; instead I wanted updates to be sent on other
port  and not TCP/53. Queries let it happen on UDP 53

On Fri, May 18, 2018 at 3:02 PM, Matus UHLAR - fantomas 
wrote:

> On 17.05.18 23:00, Blason R wrote:
>
>> I have RPZ installed on server and its acting as a master server but
>> somehow port setting is not working on master
>>
>
> # Slave configuration
>>
>> response-policy { zone "malware.trap"; };
>>
>> zone "malware.trap" {
>>  type slave;
>>  masters { 192.168.5.48; };
>>   file "/var/lib/bind/malware.trap.db";
>>  allow-notify { 192.168.5.48; };
>>
>
> this is superflous. The default is to accept notifies from master.
>
>  allow-query {localhost; };
>> };
>>
>>
>> So here I am sending notification  to 192.168.5.49 on port 4545; my
>> queries
>> are
>>
>
>   1. How do I configure port on slave 4545 so that slave server can start
>>   listening on that port.
>>
>
> why do you need to listen on port 4545 instead of default 53?
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> We are but packets in the Internet of life (userfriendly.org)
>
> ___
> 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
>
___
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

RPZ zone update how to sync

[Blason R]

Hi Guys,

I have this other query on RPZ; I have one master server [lets say
masterns.test.com.] on cloud. One slave [slavens.test.com] in my
organization and our partner would also want to sync with slave but not
with master server.

How can one slave can sync with other slave? Can someone please enlighten
me?


masterns.test.com <=>slavens.test.com <>partnerns.partner.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: also-notify and allow-notify

[Matus UHLAR - fantomas]

On 17.05.18 23:00, Blason R wrote:

So here I am sending notification  to 192.168.5.49 on port 4545; my
queries
are


  1. How do I configure port on slave 4545 so that slave server can start

  listening on that port.



On Fri, May 18, 2018 at 3:02 PM, Matus UHLAR - fantomas 
wrote:

why do you need to listen on port 4545 instead of default 53?


On 18.05.18 19:20, Blason R wrote:

Nah that is not my query; instead I wanted updates to be sent on other
port  and not TCP/53. Queries let it happen on UDP 53


notify is also a query.
try it on port 53, maybe your problem won't appear there.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
___
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: RPZ zone update how to sync

[Matus UHLAR - fantomas]

On 18.05.18 19:29, Blason R wrote:

I have this other query on RPZ; I have one master server [lets say
masterns.test.com.] on cloud. One slave [slavens.test.com] in my
organization and our partner would also want to sync with slave but not
with master server.


why? is there any logic in this?


How can one slave can sync with other slave? Can someone please enlighten
me?


masterns.test.com <=>slavens.test.com <>partnerns.partner.com


it possible without problems - just allos xfers from partner on your slave.
you can also configure your slave to notify your partner.

However I would recommend your partner trying master - this way they can
fetch the zone even if your slave fails.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...
___
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: RPZ zone update how to sync

[Blason R]

 why? is there any logic in this?

yeah management does not want to allow direct syncing with master as they
dont want to expose any info to them.

On Fri, May 18, 2018 at 7:32 PM, Matus UHLAR - fantomas 
wrote:

> On 18.05.18 19:29, Blason R wrote:
>
>> I have this other query on RPZ; I have one master server [lets say
>> masterns.test.com.] on cloud. One slave [slavens.test.com] in my
>> organization and our partner would also want to sync with slave but not
>> with master server.
>>
>
> why? is there any logic in this?
>
> How can one slave can sync with other slave? Can someone please enlighten
>> me?
>>
>>
>> masterns.test.com <=>slavens.test.com <>partnerns.partner.com
>>
>
> it possible without problems - just allos xfers from partner on your slave.
> you can also configure your slave to notify your partner.
>
> However I would recommend your partner trying master - this way they can
> fetch the zone even if your slave fails.
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Linux is like a teepee: no Windows, no Gates and an apache inside...
> ___
> 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
>
___
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: RPZ zone update how to sync

[Nico CARTRON]

> 
> On 18 May 2018, at 16:16, Blason R  wrote:
> 
> why? is there any logic in this? 
> 
> yeah management does not want to allow direct syncing with master as they 
> dont want to expose any info to them.  

Interesting statement - especially since the slave servers will serve the exact 
same data as the master! =)


> On Fri, May 18, 2018 at 7:32 PM, Matus UHLAR - fantomas  > wrote:
> On 18.05.18 19:29, Blason R wrote:
> I have this other query on RPZ; I have one master server [lets say
> masterns.test.com .] on cloud. One slave 
> [slavens.test.com ] in my
> organization and our partner would also want to sync with slave but not
> with master server.
> 
> why? is there any logic in this? 
> 
> How can one slave can sync with other slave? Can someone please enlighten
> me?
> 
> 
> masterns.test.com  <=>slavens.test.com 
>  <>partnerns.partner.com 
> 
> 
> it possible without problems - just allos xfers from partner on your slave.
> you can also configure your slave to notify your partner.
> 
> However I would recommend your partner trying master - this way they can
> fetch the zone even if your slave fails.
> 
> 
> -- 
> Matus UHLAR - fantomas, uh...@fantomas.sk  ; 
> http://www.fantomas.sk/ 
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Linux is like a teepee: no Windows, no Gates and an apache inside...
> ___
> 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 
> 
> 
> ___
> 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

___
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: RPZ zone update how to sync

[Grant Taylor via bind-users]

On 05/18/2018 08:02 AM, Matus UHLAR - fantomas wrote:

why? is there any logic in this?


I can see a case where a hidden / internal master is used and only 
accessible by direct slaves in a DMZ.


So the slaves in the DMZ act as a contact point for the world.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: also-notify and allow-notify

[Blason R]

Okies so zone xfer would happen on TCP/53 correct and notify would be sent
on udp/53?

On Fri, May 18, 2018, 7:31 PM Matus UHLAR - fantomas 
wrote:

> >> On 17.05.18 23:00, Blason R wrote:
> >>> So here I am sending notification  to 192.168.5.49 on port 4545; my
> >>> queries
> >>> are
> >>
> >>   1. How do I configure port on slave 4545 so that slave server can
> start
> >>>   listening on that port.
>
> >On Fri, May 18, 2018 at 3:02 PM, Matus UHLAR - fantomas <
> uh...@fantomas.sk>
> >wrote:
> >> why do you need to listen on port 4545 instead of default 53?
>
> On 18.05.18 19:20, Blason R wrote:
> >Nah that is not my query; instead I wanted updates to be sent on other
> >port  and not TCP/53. Queries let it happen on UDP 53
>
> notify is also a query.
> try it on port 53, maybe your problem won't appear there.
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
> ___
> 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
>
___
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: Intermittent "failure trying master... operation canceled" on zone refresh

[Matthew Pounsett]

On 17 May 2018 at 17:05, Rob Moser  wrote:

> We're running a series of RHEL 7.4 machines (kernel version
> 3.10.0-693.1.1.el7.x86_64) running bind version 9.9.4-RedHat-9.9.4-51.el7.
> Our configuration consists of a hidden master and three hidden
> slave/recursive resolvers.  I'm getting a LOT of errors on the slaves that
> look like:
>
> 17-May-2018 13:27:28.421 general: info: zone 
> 34.22.10.in-addr.arpa/IN/internal-view:
> refresh: failure trying master 10.20.30.3#53 (source 0.0.0.0#0): operation
> canceled
>
> In addition to checking for firewalls and other stateful network devices
as Tony mentions, you should also have a look at the condition of the
network in between the hosts.  That feels a lot like moderate packet loss,
or extreme latency, to me.

Are these machines all on the same LAN?  Are there multiple networks in
between them?
___
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: also-notify and allow-notify

[Matus UHLAR - fantomas]

On 18.05.18 23:07, Blason R wrote:

Okies so zone xfer would happen on TCP/53 correct and notify would be sent
on udp/53?


maybe and maybe not.
both tcp/53 nd udp/53 are mandatory, and both can be used for any kind of
DNS traffic.


On Fri, May 18, 2018, 7:31 PM Matus UHLAR - fantomas 
wrote:


>> On 17.05.18 23:00, Blason R wrote:
>>> So here I am sending notification  to 192.168.5.49 on port 4545; my
>>> queries
>>> are
>>
>>   1. How do I configure port on slave 4545 so that slave server can
start
>>>   listening on that port.

>On Fri, May 18, 2018 at 3:02 PM, Matus UHLAR - fantomas <
uh...@fantomas.sk>
>wrote:
>> why do you need to listen on port 4545 instead of default 53?

On 18.05.18 19:20, Blason R wrote:
>Nah that is not my query; instead I wanted updates to be sent on other
>port  and not TCP/53. Queries let it happen on UDP 53

notify is also a query.
try it on port 53, maybe your problem won't appear there.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
___
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

CVE-2018-5736: Multiple transfers of a zone in quick succession can cause an assertion failure in rbtdb.c

[Michael McNally]

CVE: CVE-2018-5736
Document Version:2.0
Posting date:18 May 2018
Program Impacted:BIND
Versions affected:   9.12.0 and 9.12.1
Severity:Medium
Exploitable: Remotely, if an attacker can trigger a zone transfer

Description:

   An error in zone database reference counting can lead to an
   assertion failure if a server which is running an affected version
   of BIND attempts several transfers of a slave zone in quick
   succession.

   This defect could be deliberately exercised by an attacker who
   is permitted to cause a vulnerable server to initiate zone
   transfers (for example: by sending valid NOTIFY messages), causing
   the named process to exit after failing the assertion test.

Impact:

   Authoritative servers that serve slave zones are vulnerable to
   potential denial of service if all of the following are true:

   +  they are running an affected version of BIND (BIND 9.12.0
  or 9.12.1)
   +  at least one of the zones for which they are providing service
  is of type "slave"
   +  they permit NOTIFY messages from any source.

CVSS Score:  5.3
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Workarounds:

   For servers which must receive notifies to keep slave zone
   contents current, no complete workarounds are known although
   restricting BIND to only accept NOTIFY messages from authorized
   sources can greatly mitigate the risk of attack.

Active exploits:

   No known active exploits.

Solution:

   The reference counting error which can be exploited in this
   vulnerability is present in only two public release versions of
   BIND, 9.12.0 and 9.12.1.  If you are running an affected version
   then upgrade to BIND 9.12.1-P1

Acknowledgements:

   ISC would like to thank SWITCH for informing us of this vulnerability.

Document Revision History:

   1.0 Advance Notification 09 May 2018
   2.0 Public Disclosure 18 May 2018

Related Documents:

   See our BIND9 Security Vulnerability Matrix at
   https://kb.isc.org/article/AA-00913 for a complete listing of
   Security Vulnerabilities and versions affected.

Do you still have questions?  Questions regarding this advisory
should go to security-offi...@isc.org.  To report a new issue,
please encrypt your message using security-offi...@isc.org's PGP
key which can be found here:
   https://www.isc.org/downloads/software-support-policy/openpgp-key/.
If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01602 is
the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.


(c) 2001-2018 Internet Systems Consortium
___
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

BIND 9.12.1-P2 is now available

[Michael McNally]

A new version of BIND is available to address two vulnerabilities
disclosed today: CVE-2018-5736 and CVE-2018-5737; see the respective
messages on this mailing list or consult the ISC Knowledge Base
https://kb.isc.org/category/74/0/10/Software-Products/BIND9/Security-Advisories/.

Only two releases in the BIND 9.12 branch were affected by these
vulnerabilities and BIND 9.12.1-P2 corrects both issues.  The new
release can be found via our software download page:

   https://www.isc.org/downloads

Finally, a word of apology for the awkward timing of this diclosure.
At ISC we usually try to avoid the very beginning or end of the week
for our vulnerability disclosures because time zone factors can make
those times particularly awkward for operators in other parts of the
world.  In this particular instance we had originally scheduled our
disclosure for Wednesday (16 May) but were forced to delay the
release when a last-minute flaw was found in BIND 9.12.1-P1, leading
to its withdrawal and replacement with BIND 9.12.1-P2.  Unfortunately
the vulnerabilities were partly disclosed at that stage and we
decided that the safest course was to proceed as directly as possible
to public disclosure, rather than risk a leak.  We do regret the
inconvenience that will be incurred by server operators due to the
timing of this announcement.

Michael McNally
ISC Security Officer
___
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

CVE-2018-5737: BIND 9.12's serve-stale implementation can cause an assertion failure in rbtdb.c or other undesirable behavior, even if serve-stale is not enabled.

[Michael McNally]

CVE: CVE-2018-5737
Document Version:2.0
Posting date:18 May 2018
Program Impacted:BIND
Versions affected:   9.12.0, 9.12.1
Severity:Medium
Exploitable: Remotely

Description:

   A problem with the implementation of the new serve-stale feature
   in BIND 9.12 can lead to an assertion failure in rbtdb.c, even
   when stale-answer-enable is off.  Additionally, problematic
   interaction between the serve-stale feature and NSEC aggressive
   negative caching can in some cases cause undesirable behavior
   from named, such as a recursion loop or excessive logging.

   Deliberate exploitation of this condition could cause operational
   problems depending on the particular manifestation -- either
   degradation or denial of service.

Impact:

   Servers running a vulnerable version of BIND (9.12.0, 9.12.1)
   which permit recursion to clients and which have the max-stale-ttl
   parameter set to a non-zero value are at risk.

CVSS Score:  5.9
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Workarounds:

   Setting "max-stale-ttl 0;" in named.conf will prevent exploitation
   of this vulnerability (but will effectively disable the serve-stale
   feature.)

   Setting "stale-answer enable off;" is not sufficient to prevent
   exploitation, max-stale-ttl needs to be set to zero.

Active exploits:

   No known active exploits.

Solution:

   The error which can be exploited in this vulnerability is present
   in only two public release versions of BIND, 9.12.0 and 9.12.1.
   If you are running an affected version then upgrade to BIND
   9.12.1-P2

Acknowledgements:

   ISC would like to thank Tony Finch of the University of Cambridge
   for his assistance in discovering and analyzing this vulnerability.

Document Revision History:

   1.0 Advance Notification, 09 May 2018
   1.1 BIND 9.12.1-P1 was recalled before public announcement
   due to defect, the advisory language was re-written to be
   clearer about the exploit risk, and the public disclosure
   date was adjusted because of the problem with 9.12.1-P1,
   17 May 2018
   2.0 Public Disclosure, 18 May 2018

Related Documents:

   See our BIND9 Security Vulnerability Matrix at
   https://kb.isc.org/article/AA-00913 for a complete listing of
   Security Vulnerabilities and versions affected.

If you'd like more information on ISC Subscription Support and
Advance Security Notifications, please visit http://www.isc.org/support/.

Do you still have questions?  Questions regarding this advisory
should go to security-offi...@isc.org.  To report a new issue,
please encrypt your message using security-offi...@isc.org's PGP
key which can be found here:
   https://www.isc.org/downloads/software-support-policy/openpgp-key/.
If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01606 is
the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.

(c) 2001-2018 Internet Systems Consortium
___
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

v9.12.1-P2 changed files

[Jim Popovitch via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Honest question Why are there so many sourcecode
modifications/additions/deletions between v9.12.1 and v9.12.1-P2?  Some 
files should obviously change between minor versions, but ~1300 ?

Bin9 v9.12.1-P2 changed files:
http://paste.debian.net/plainh/470058dd

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlr/N2gACgkQJxVetMRa
JwU02w//bWw5TAoVjmTsMlUJndA7Yd3DM14fsWBMTBGGxKYZjG9JskBOOoGYFrbZ
gR+ljJAGEOTRBGYStG6f+M7ocPK9brXVpFiqhGB/cG0ntM9vgczKWC0HjWHvQuZf
3vdqu6hs77fQyxy82mkOeVB/dRCJdbAQWt7I7ezstWhvlYqs+HVJRONimnK/dnID
swBa9A4Mn+ln606eW8pBVOAML1jj/Eo+Euo+PMAoT7UfNXIz267uf53heOtMe+hZ
NSf71wisYEbG04qbUxeJRgSTGBhb3b4TRYIWLKYm1d0wg75gUApdAsTvPDf9DUpD
pmxckTy5feuQt2wXRlrq1yanuXLTHlesfQfTj/Kq4QnAlcC2HxdzVkrc55ogVmmM
aVa4NDbwL0Q0FKHVzRjRc3d0xFGy6cHWVDiE02zsEqN0syRCGc9Frhck+P6BpD3O
gIwC2WmPDwBkBCGNk91BiGD+yDtz9YR7L4tkHouvbNvkeJ6fYVTnTTSqH9oPfSSF
2q1ENTUrtZT2rrkzlUIFsdFGskOTHyr6KPxyC0ZlRsS+/lOr+SI3fZqyeo8JfZ05
Mmfu2m0YlKRKk4yXcjA1TwPRXCmUN+TfFPRK87aDGaCWTGupbTbFvhpmPWtjYvJi
crOw9F7AzPdqzJaPKdu1lZUBPxlwXDk+9OZK1IHVONShhPiluys=
=hod6
-END PGP SIGNATURE-

___
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: v9.12.1-P2 changed files

[Ray Bellis]

On 18/05/2018 21:28, Jim Popovitch via bind-users wrote:
> Honest question Why are there so many sourcecode
> modifications/additions/deletions between v9.12.1 and v9.12.1-P2?  Some 
> files should obviously change between minor versions, but ~1300 ?
> 
> Bin9 v9.12.1-P2 changed files:
> http://paste.debian.net/plainh/470058dd

The vast majority of those changes are due to a change to the standard
copyright template at the top of each source file.

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

RHEL, Centos, Fedora rpm 9.12.1-P2

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

http://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlr/TNkACgkQL6j7milTFsHqPQCfVCKLfx5wzLjm+UkCkJx2C6f1
AkwAnikf8H/hDq+yQJL+oVfoaQ3C9ffX
=il2P
-END PGP SIGNATURE-


___
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: v9.12.1-P2 changed files

[Evan Hunt]

On Fri, May 18, 2018 at 04:28:24PM -0400, Jim Popovitch via bind-users wrote:
> Honest question Why are there so many sourcecode
> modifications/additions/deletions between v9.12.1 and v9.12.1-P2?  Some 
> files should obviously change between minor versions, but ~1300 ?

Are you sure you're comparing against 9.12.1? I think you might be looking
at a 9.11 release.  The list in your pastebin link mentioned files in
lib/lwres having been removed, but those files weren't in 9.12.1, they
were removed in 9.12.0.

According to the git repo, the only source files that were modified between
9.12.1 and 9.12.1-P2 are:

lib/dns/rbtdb.c
lib/dns/zone.c
lib/ns/include/ns/query.h
lib/ns/query.c

And all other differences are from rebuilding the documentation with the
new version number.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: v9.12.1-P2 changed files

[Jim Popovitch via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2018-05-19 at 01:03 +, Evan Hunt wrote:
> On Fri, May 18, 2018 at 04:28:24PM -0400, Jim Popovitch via bind-
> users wrote:
> > Honest question Why are there so many sourcecode
> > modifications/additions/deletions between v9.12.1 and v9.12.1-
> > P2?  Some 
> > files should obviously change between minor versions, but ~1300 ?
> 
> Are you sure you're comparing against 9.12.1? I think you might be
> looking at a 9.11 release.  The list in your pastebin link mentioned
> files in lib/lwres having been removed, but those files weren't in
> 9.12.1, they were removed in 9.12.0.

Ahhh, Doh!  I failed to sync (bzr push) my v9.12.1 build tree to my
launchpad archive, so when I branch'ed it to my new dev system I was
starting with the v9.11.3 release.  The launchpad change log clearly
shows this. sigh.

rev-26. By Jim Popovitch 10 hours ago
Upstream v9.12.1-P2 release

rev-25. By Jim Popovitch on 2018-04-28
Upstream v9.11.3 release

rev-24. By Jim Popovitch on 2018-01-30
Bind9 v9.11.2-P1 ISC Release


> According to the git repo, the only source files that were modified
> between 9.12.1 and 9.12.1-P2 are:
> 
> lib/dns/rbtdb.c
> lib/dns/zone.c
> lib/ns/include/ns/query.h
> lib/ns/query.c
> 
> And all other differences are from rebuilding the documentation with
> the new version number.

I really need to switch my dev env to pull the changes from git.  

Thanks Evan!

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlr/wVoACgkQJxVetMRa
JwVa+BAAlRx7kR7T5M7NK8lz1DDuA1hcsYSg2MJcslZmdqxudx4BFiegy6pg8HOx
RdbiyowO+t4OTCWsndzEt7yiEtyM2vR0ZAbeZAjhhFveWFZROAnQFBnJxePTnVJh
kOEb9p1comsdRy2IhqSIVmyZGwFCpU1cB0XkzmAj+yWqA2IAPrWG0/veUv0X+YXi
QcT1PVDkgFMSGMXC8oCoT3udqjXrb6zSfHU5L5bU7caRkhpxkYvb9HGwmu9shPe/
XH54wtsTssNZaZX2H+b9NylqsLQRhqzzskYlvZmzu/JYvQToSBUcmOUjnyuJJzOW
US1B5gfU8S19EnXT/UxbMz0bal9lAuuzCWtODXiFo8CNgt5mf75lup5g6Y+/XEZr
Hd7dsavLgA83VzwkAwuR2JCGMKCOcCF4jL7pxuy+NuIsN31OjTyGJgv/L4aH0leM
hj1D28IrJBSGNh4BAAqy1+RIuJyeXfaElI6ZsVYTZvUpsUZp2RjZNETYs1RgwEbR
DPDofD8Niiw9ub727xILz1VBdoD02WW6oZcTIHXuerExO+GZ0c6vVMwJV3dxhGF/
jgc8xDCZoXEuwvmMMm6bH+AD77YvYPyL2+vY1C+cPGZ3JWAI7oW09kOLLDyEZ9tl
uQFfBSCJBr8QWtvF+zNPpsgr9ZPaPdX96+PSQJZ0LSqFAu88N5c=
=LqAT
-END PGP SIGNATURE-

___
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