AW: AW: Problems with Zone transfers

[Fernando Costa de Almeida]

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   200.150.208.3:1645    *:*

This server has 3 different ip address, and radiusd was configured to 
bind to only the address 200.150.208.3 (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 200.150.208.2: unknown 
packet code 103
Error: WARNING: Malformed RADIUS packet from host 200.150.208.2: 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 200.150.208.3#5000: query: monacobicicletas.com.br IN SOA
client 200.150.208.3#5000: query: choppodromo.com.br IN SOA

I wish to thanks everyone who helped me out!

Fernando


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

-- 
_______________________________________
ALMEIDA, Fernando Costa de
Computeasy Informática
www.computeasy.com.br
BSD USER BSD050945
ICQ 72293951