Re: slave timers

2011-04-20 Thread Matus UHLAR - fantomas
On 19.04.11 15:42, hugo hugoo wrote:
 I have in fact the following problem:
  
 The AXFR is not triggered by a “rndc reload”, neither a stop/start of bind9. 

are you doing those on slave?

   è nothing is seen in the logs

I believe you can see in bind logs at least the fact that you issued rndc
reload and/or stopped/started BIND.

 The AXFR is triggered by a “rndc reload zonename”.

in fact, after you ask slave to issue relaod specific zone, the slave checks
whether the zone needs to be reloaded.

 = logs of the master
  
 pr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854: 
 transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR started
 Apr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854: 
 transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR ended
  
  
 è logs in the slave
  
 pr 19 17:32:10 lennydnstest01 named[4614]: received control channel command 
 'reload bind9testcarlos.be'
 Apr 19 17:32:10 lennydnstest01 named[4614]: zone bind9testcarlos.be/IN: 
 Transfer started.
 Apr 19 17:32:10 lennydnstest01 named[4614]: transfer of 
 'bind9testcarlos.be/IN' from 194.78.73.65#53: connected using 
 194.78.73.88#37854
 Apr 19 17:32:10 lennydnstest01 named[4614]: zone bind9testcarlos.be/IN: 
 transferred serial 1999101714
 Apr 19 17:32:10 lennydnstest01 named[4614]: transfer of 
 'bind9testcarlos.be/IN' from 194.78.73.65#53: Transfer completed: 1 messages, 
 8 records, 250 bytes, 0.005 secs (5 bytes/sec)
  
 Is this behavior normal?

this is normal log of a zone transfer.

 On the slave: (before the rndc reload zonename)

what's on the slave AFTER reload zonename?

-- 
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.
42.7 percent of all statistics are made up on the spot. 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: slave timers

2011-04-19 Thread hugo hugoo

Hello,
 
I have in fact the following problem:
 
The AXFR is not triggered by a “rndc reload”, neither a stop/start of bind9. 
 
  è nothing is seen in the logs
 
 
The AXFR is triggered by a “rndc reload zonename”.
 
= logs of the master
 
pr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854: 
transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR started
Apr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854: 
transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR ended
 
 
è logs in the slave
 
pr 19 17:32:10 lennydnstest01 named[4614]: received control channel command 
'reload bind9testcarlos.be'
Apr 19 17:32:10 lennydnstest01 named[4614]: zone bind9testcarlos.be/IN: 
Transfer started.
Apr 19 17:32:10 lennydnstest01 named[4614]: transfer of 'bind9testcarlos.be/IN' 
from 194.78.73.65#53: connected using 194.78.73.88#37854
Apr 19 17:32:10 lennydnstest01 named[4614]: zone bind9testcarlos.be/IN: 
transferred serial 1999101714
Apr 19 17:32:10 lennydnstest01 named[4614]: transfer of 'bind9testcarlos.be/IN' 
from 194.78.73.65#53: Transfer completed: 1 messages, 8 records, 250 bytes, 
0.005 secs (5 bytes/sec)
 
 
Is this behavior normal?
 
 
Zone on the master
 
$TTL 3600;Positive Caching
bind9testcarlos.be.  86400   IN SOA  ns1.skynet.be.  dnsmaster.skynet.be.   
 (
 1999101714 ; Serial
 10800  ; Refresh
 3600   ; Retry
 604800 ; Expire
 86400 ); Negative Caching
 
bind9testcarlos.be.  86400   IN  NS ns.uat.
bind9testcarlos.be.  86400   IN  NS ns2.uat.
cs1.sgtest1.bind9testcarlos.be.  3600IN  A   1.2.3.4 
ns.bind9testcarlos.be.   3600IN  A   1.2.3.4
ns2.bind9testcarlos.be.  3600IN  A   1.2.3.4 
sgtest1.bind9testcarlos.be.  3600IN  A   1.2.3.7
 
 
On the slave: (before the rndc reload zonename)
 
 
dig @localhost bind9testcarlos.be AXFR
 
;  DiG 9.6-ESV-R3  @localhost bind9testcarlos.be AXFR
; (2 servers found)
;; global options: +cmd
bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
dnsmaster.skynet.be. 1999101713 10800 3600 604800 86400
bind9testcarlos.be. 86400   IN  NS  ns.uat.
bind9testcarlos.be. 86400   IN  NS  ns2.uat.
ns.bind9testcarlos.be.  3600IN  A   1.2.3.4
ns2.bind9testcarlos.be. 3600IN  A   1.2.3.4
sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.6
cs1.sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.4
bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
dnsmaster.skynet.be. 1999101713 10800 3600 604800 86400
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 19 17:30:27 2011
;; XFR size: 8 records (messages 1, bytes 250)
 
 
 
Thanks in advance for your feedback,
 
Hugo,
 
___

 

 
 Date: Mon, 18 Apr 2011 11:19:48 -0500
 From: jay-f...@uiowa.edu
 To: hugo...@hotmail.com
 CC: bind-users@lists.isc.org
 Subject: Re: slave timers
 
 On Mon, 18 Apr 2011, hugo hugoo wrote:
  I am testing the migration bind8 to Bind9 and the working for slave zones.
  
  To do this, I have put the following values to the timers in the master 
  zone.
  
  $ORIGIN com.
  toto 3600 IN SOA ns1.toto.com. postmaster.toto.com. (
 
  2011041404 302 3600 604800 3600 )
 
  It is really not working good!
  
  - Are there some constraint in the timer values?
 
  For my test I have a 302 seconds expired time can this work even if
  this timer is smaller than the other ones?
 
 The second parameter is the refresh timer, not the expire timer.
 
 302 seconds is pretty short. Assuming your master-slave notifies are
 working correctly an hour or 2 (3600 or 7200 seconds) should be fine for a
 refresh timer value, but there are probably valid reasons to use shorter
 values.
 
  - When I do a 'rndc reload' on the slave name server, there is no AXFR
  request to the Master.
 
  - When I do a bind9 stop/start on the slave name server, there is no AXFR
  request to the master.
  
  - There is no AXFR request to the master every 302 seconds.
 
 The slave will check the SOA serial number it has against that of the master.
 If the master's is newer, it will transfer the zone. If not, the slave has
 current data so doesn't need to transfer it again.
 
 Are you incrementing the SOA serial number on the master?
 
 rndc retransfer zone on the slave will force a transfer, ignoring the SOA
 serial number. See if that works.
 
 
 Jay Ford, Network Engineering Group, Information Technology Services
 University of Iowa, Iowa City, IA 52242
 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: slave timers

2011-04-19 Thread David Sparro

On 4/19/2011 11:42 AM, hugo hugoo wrote:

Hello,

I have in fact the following problem:

The AXFR is not triggered by a “rndc reload”, neither a stop/start of
bind9.

ènothing is seen in the logs

The AXFR is triggered by a “rndc reload zonename”.

= logs of the master

pr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854:
transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR started

Apr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854:
transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR ended



An AXFR will not be initiated by the slave if it determines that it is 
not needed based on a query of the master's SOA serial number.


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


RE: slave timers

2011-04-19 Thread hugo hugoo

In my example, the serial number is greater in the master than  the serial 
number in the slave.
So a zone transfer must be done but it is not done after a rdnc reload or a 
start/stop.

The zone transfer is directly done after a rndc reload zonename


How can I go on investigating what happens?
Is it possible to visualise the value of the refresh timer of a zone? Any other 
idea?


Hugo,




 Date: Tue, 19 Apr 2011 12:06:54 -0400
 From: dspa...@gmail.com
 To: bind-users@lists.isc.org
 Subject: Re: slave timers
 
 On 4/19/2011 11:42 AM, hugo hugoo wrote:
  Hello,
 
  I have in fact the following problem:
 
  The AXFR is not triggered by a “rndc reload”, neither a stop/start of
  bind9.
 
  ènothing is seen in the logs
 
  The AXFR is triggered by a “rndc reload zonename”.
 
  = logs of the master
 
  pr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854:
  transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR started
 
  Apr 19 17:32:03 dnscustmaster901 named[5672]: client 194.78.73.88#37854:
  transfer of 'bind9testcarlos.be/IN': AXFR-style IXFR ended
 
 
 An AXFR will not be initiated by the slave if it determines that it is 
 not needed based on a query of the master's SOA serial number.
 
 -- 
 Dave
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: slave timers

2011-04-19 Thread Eivind Olsen
hugo hugoo wrote:
 How can I go on investigating what happens?

In your previous message you listed these nameservers in the zonefile:

bind9testcarlos.be.  86400   IN  NS ns.uat.
bind9testcarlos.be.  86400   IN  NS ns2.uat.

Is the slave server you're having problems with one of these two (ns.uat /
ns2.uat)? If it isn't, have you told the master nameserver about the slave
with for example the also-notify  option?
How have you configured BIND on the master nameserver, with regards to
notify settings?

Regards
Eivind Olsen
eiv...@aminor.no



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


slave timers

2011-04-18 Thread hugo hugoo

Dear all,
 
I am testing the migration bind8  to Bind9 and the working for slave zones.
To do this, I have put the following values to the timers in the master zone.
 
$ORIGIN com.
toto  3600IN  SOA ns1.toto.com. postmaster.toto.com. (
2011041404 302 3600 604800 3600 )
….
….
 
It is really not working good!
 
- Are there some constraint  in the timer values?
  For my test I have a 302 seconds expired time  è can this work even if this 
timer is smaller than the other ones?
 
- When I do a “rndc reload” on the slave name server, there is no AXFR request 
to the Master.
 
- When I do a bind9 stop/start on the slave name server, there is no AXFR 
request to the master.
 
- There is no AXFR request to the master every 302 seconds.
 
 
Can anyone help me to understand?
 
Thanks in advance,
 
Hugo, ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: slave timers

2011-04-18 Thread Jay Ford

On Mon, 18 Apr 2011, hugo hugoo wrote:

I am testing the migration bind8  to Bind9 and the working for slave zones.

To do this, I have put the following values to the timers in the master zone.

$ORIGIN com.
toto  3600IN  SOA ns1.toto.com. postmaster.toto.com. (

2011041404 302 3600 604800 3600 )



It is really not working good!

- Are there some constraint  in the timer values?

  For my test I have a 302 seconds expired time   can this work even if
this timer is smaller than the other ones?


The second parameter is the refresh timer, not the expire timer.

302 seconds is pretty short.  Assuming your master-slave notifies are
working correctly an hour or 2 (3600 or 7200 seconds) should be fine for a
refresh timer value, but there are probably valid reasons to use shorter
values.


- When I do a 'rndc reload' on the slave name server, there is no AXFR
request to the Master.

- When I do a bind9 stop/start on the slave name server, there is no AXFR
request to the master.

- There is no AXFR request to the master every 302 seconds.


The slave will check the SOA serial number it has against that of the master.
If the master's is newer, it will transfer the zone.  If not, the slave has
current data so doesn't need to transfer it again.

Are you incrementing the SOA serial number on the master?

rndc retransfer zone on the slave will force a transfer, ignoring the SOA
serial number.  See if that works.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users