Network delay kills zone transfers?

[Christopher Earley]

Folks,

	Just wondering if anyone answered Matt Larson's question
from May 28th (and my news server failed to suck it in)?

	I've got the same exact problem with a secondary server
in Singapore (xfer from a primary in New York).  Truss of relevant
procs shows numerous EAGAIN errors.  At first I suspected memory &
swap problems, but a memory and swap boost hasn't helped, and the
Stevens books mention that EAGAIN is sometimes synonomous with the
EWOULDBLOCK error for network reads, so lost/slow packets might be
the issue.

	I've got named 4.9.3-P1 on Solaris 2.5.1 for the failing
secondary.  An answer to Matt's question would be a great help.

Thanks,

Christopher Earley
Periphonics Corporation
cearley at peri.com


Matt Larson wrote:
> 
> Hi, folks.
> 
> I've got a customer with a slave about 600ms away from its master
> server.  The slave is unable to perform zone transfers: they start and run
> for a few minutes, only to die with this familiar error on the slave:
> 
> zoneref: Masters for secondary zone "x.y.z.IN-ADDR.ARPA" unreachable
> 
> (I'm sorry to be flaky and blank out the zone name, but this is one of
> those "I could tell you but then I'd have to kill you" organizations.)
> 
> Only this one topologically distant name server has this problem; the other
> slaves are fine.  This remote name server is a slave for several zones from
> the same master and all fail similarly.  This remote slave can ping the
> master just fine, albeit with the 600ms delay.  Both servers run a recent
> version of AIX (not sure which version) running the BIND name server
> shipped by IBM, which is 4.9.something.
> 
> Is named-xfer not able to cope with this much latency?  Or could that be a
> red herring?
> 
> I'd be grateful for any ideas.
> 
> Thanks,
> 
> Matt
> 
> --
> Matt Larson <matt at acmebw.com>
> Acme Byte & Wire / http://www.acmebw.com