AW: AW: Problems with Zone transfers
Benjamin.Walkenhorst at telekom.de
Fri Dec 10 08:31:47 UTC 2004
I just notice, in your original posting you quoted the log:
> named: zone ativo.com.br/IN: refresh: failure trying master
> 188.8.131.52#53: timed out
The slave is not trying to do a zone transfer, 'refresh' means the slave
is asking the master for the serial to see if a zone transfer is neccessary.
> I also noticed something very strange...
> When I change some data in the master, and notifies are sent to the
> slaves, the transfer occurs without problems.
Upon receiving a notify, the slave should ask the master for its serial and
do a zone transfer if the serial has changed.
Notifies are sent out when a zone's serial has changed, so it's not uncommon
to see zone transfers happen afterwards. =)
> The problem occurs only when the REFRESH time expires and the slaves
> automatically try to refresh the zone.
> The other strange behaviour is that the slaves are trying to transfer
> the zones even though they are not newer than the version they have.
Are you sure? The above quote from your log says to me the slave was only trying
to do a refresh, not neccessarily a zone transfer.
Still, this does not explain the timeout, if zone transfers are working fine.
I notice that in "my" zones the refresh value is higher than the "minimum" value,
but I cannot see how this would cause a timeout. ;-/
Anyway, unless you change your zone data on a daily base, you can safely increase the
refresh to something like three to four hours, especially when using notify.
Is upgrading to 9.3 an option? If so, you should do so.
I suggest turning up the debug level on master and slave and/or using a network sniffer
like tcpdump or ethereal. Look if the refresh messages actually arrive at the master and
if it does anything about them. Maybe the master for some reason decides to ignore the refresh
messages or does not ever receive them due to... maybe a misconfigured packet filter on one of
More information about the bind-users