problem with ixfr

Kevin Darcy kcd at
Sat Jun 3 03:23:50 UTC 2006

Carl Byington wrote:
> Hash: SHA1
> contains the zone which is
> fairly large (137K records). used to do IXFR
> transfers, but after moving that machine to a different network, it now
> only does AXFR transfers.
> from ns1, we can 'dig ixfr=2006052704 @ns' and
> get the delta update.
> from ns, we can 'dig ixfr=2006052704 @ns1' and
> get the delta update.
> Do those dig commands not emulate what bind itself is doing internally to
> request the zone transfer?
It should look somewhat similar. The only potential difference that 
comes to mind immediately is the use/non-use of EDNS0 and/or the EDNS0 
buffer size that is negotiated between the master and slave. Potentially 
that might result in a different packet size, one that might be more 
likely to be dropped/truncated/corrupted by intermediary firewalls, 
routers or other network devices. You could try turning off EDNS0 
completely in respective "server" statements, to see if that has any 
effect on the behavior.

                           - Kevin

More information about the bind-users mailing list