Multi-Master and NOTIFY

Tom Daly tom at dyndns.com
Fri Dec 1 15:22:04 UTC 2006


> 	That is incorrect.  See lib/dns/zone.c:refresh_callback().

We've checked that out and verified that in our lab setup. Thanks.

With our own test setup, i.e. our own masters, this problem does not occur 
at all. If the serial number on the first master is lower than the second 
master, it pulls the update from the second master. From our logs, that 
looks like this:

Nov 30 14:38:40 sec1 named[12057]: client yyy.yyy.yyy.yyy#62825: view 
tom-tld: received notify for zone 'example'
Nov 30 14:38:40 sec1 named[12057]: zone example/IN/tom-tld: serial number 
(2006113025) received from master xxx.xxx.xxx.xxx#53 < ours (2006113030)
Nov 30 14:38:41 sec1 named[12057]: zone example/IN/tom-tld: Transfer 
started.
Nov 30 14:38:41 sec1 named[12057]: transfer of 'example/IN' from 
yyy.yyy.yyy.yyy#53: connected using aaa.aaa.aaa.aaa#1438
Nov 30 14:38:41 sec1 named[12057]: zone example/IN/tom-tld: transferred 
serial 2006113035
Nov 30 14:38:41 sec1 named[12057]: transfer of 'example/IN' from 
204.13.251.38#53: end of transfer

When our client has this same problem, the relevant log lines look like 
this:

Nov 25 00:59:29 sec1 named[12057]: client yyy.yyy.yyy.yyy#1050: view 
client-tld: received notify for zone 'client'
Nov 25 00:59:59 sec1 named[12057]: zone client/IN/client-tld: refresh: 
retry limit for master xxx.xxx.xxx.xxx#53 exceeded (source aaa.aaa.aaa.aaa#53)
Nov 25 00:59:59 sec1 named[12057]: zone client/IN/client-tld: Transfer 
started.
Nov 25 00:59:59 sec1 named[12057]: transfer of 'client/IN' from 
xxx.xxx.xxx.xxx#53: connected using aaa.aaa.aaa.aaa#3099
Nov 25 00:59:59 sec1 named[12057]: transfer of 'client/IN' from 
xxx.xxx.xxx.xxx#53: end of transfer

In both examples, xxx.xxx.xxx.xxx represents the first master defined. 
yyy.yyy.yyy.yyy represents the second master defined. aaa.aaa.aaa.aaa 
represents sec1's address.

In the client case, it appears that something is happening to the 
xxx.xxx.xxx.xxx master, which causes it to timeout for 30 seconds, but 
then transfer the zone. From these logs, I cannot tell if the second 
master is checked or not.

Is there anything I can to the log verbosity to check this?

Any other thoughts?

Tom Daly

-- 
Thomas J. Daly
tom at dyndns.com
Dynamic Network Services, Inc.
http://www.dyndns.com/



More information about the bind-users mailing list