AW: AW: Problems with Zone transfers

Fernando Costa de Almeida falmeida at
Fri Dec 10 13:41:59 UTC 2004

After a long time doing diagnostics in the network, I finally found what 
was wrong.

Sometimes, bind started to use the source port 1645 for the refresh 
queries, but (and this is very strange), this port was already been in 
use by other daemon:

bind     named    45256   30 udp4   *:1645                *:*
nobody   radiusd  66448    3 udp4    *:*

This server has 3 different ip address, and radiusd was configured to 
bind to only the address (that's why I believe that bind 
thinks that it could use this port).

So, the queries arrives to the master, but when the master send the 
answer to the slave, the radiusd is the proccess that actually receives 
the packet:

Error: WARNING: Bad RADIUS packet from host unknown 
packet code 103
Error: WARNING: Malformed RADIUS packet from host too 
long (length 33920 > maximum 4096)

Now I put the following in the confs of the slaves:

transfer-source <ip> port 5000;

And the timeouts are gone!

client query: IN SOA
client query: IN SOA

I wish to thanks everyone who helped me out!


Walkenhorst, Benjamin wrote:
> Hello,
> I just notice, in your original posting you quoted the log:
>>named[15805]: zone refresh: failure trying master 
>> 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
> the machines. 
> Kind regards,
> Benjamin

ALMEIDA, Fernando Costa de
Computeasy Informática
ICQ 72293951

More information about the bind-users mailing list