AW: AW: Problems with Zone transfers
Mark_Andrews at isc.org
Fri Dec 10 21:57:33 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 18.104.22.168:1645 *:*
> This server has 3 different ip address, and radiusd was configured to
> bind to only the address 22.214.171.124 (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 126.96.36.199: unknown
> packet code 103
> Error: WARNING: Malformed RADIUS packet from host 188.8.131.52: 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 184.108.40.206#5000: query: monacobicicletas.com.br IN SOA
> client 220.127.116.11#5000: query: choppodromo.com.br IN SOA
> I wish to thanks everyone who helped me out!
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: zone ativo.com.br/IN: refresh: failure trying master
> >>18.104.22.168#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
> > 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
> > to do a refresh, not neccessarily a zone transfer.
> > Still, this does not explain the timeout, if zone transfers are working fin
> > I notice that in "my" zones the refresh value is higher than the "minimum"
> > 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
> 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
More information about the bind-users