AW: AW: Problems with Zone transfers

[Mark Andrews]

> 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

	Upgrade to 9.2.4/9.3.0.

1681.   [bug]           Only set SO_REUSEADDR when a port is specified in
                        isc_socket_bind(). [RT #11742]

> 
> 
> 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 uncommo
> n
> > 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 t
> rying
> > to do a refresh, not neccessarily a zone transfer.
> > 
> > Still, this does not explain the timeout, if zone transfers are working fin
> e.
> > 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 in
> crease 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 net
> work sniffer
> > like tcpdump or ethereal. Look if the refresh messages actually arrive at t
> he 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 pack
> et 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
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org