can't get ixfr to work

Kevin Darcy kcd at daimlerchrysler.com
Sat May 26 02:30:06 UTC 2001


At a bare minimum, you'd need

server x.x.x.x {
    support-ixfr yes;
};

in the slave's named.conf file, referring to the master's IP address of course. That's enough to at least
get the slave to *attempt* IXFR. As for getting them to actually *do* incremental transfers, I haven't got
that to work, but then I haven't spent a _whole_ lot of time on it either. My initial packet traces
indicate that the master always sends the entire contents of the zone, even when an IXFR is requested (and
yes, I'm using Dynamic Update for all my updates, so there are tons of .ixfr files on the master; that's
not the problem). In other words, named considers it an IXFR transfer but it's not really incremental at
all.

Basically, I'm looking forward to a sane IXFR implementation in BIND 9...


- Kevin

Hannah O Day wrote:

> Kevin,
>
> I'm running bind8.2.3 on both master and slave servers.  I assume it should
> do incremental zone transfer.  But the log still shows full zone transfer
> (axfr).  Do I need to do anything to make it happen?
>
> Thanks!
> Hannah Day
> -----
>
>
>                     Kevin Darcy
>                     <kcd at daimlerchr       To:     bind-users at isc.org
>                     ysler.com>            cc:
>                     Sent by:              Subject:     Re: single class B zone vs multiple class C zone
>                     bind-users-boun
>                     ce at isc.org
>
>
>                     05/25/01 05:18
>                     PM
>
>
>
> Yes, you may run into performance issues, since the zone will be larger and
> probably change more frequently. This will greatly increase your
> zone-transfer
> overhead. On the other hand, it may reduce your serial-number-query
> overhead,
> since there are now less zones for the slave to check. But the
> serial-number-query overhead is usually a small fraction of the
> zone-transfer
> overhead, so you'll probably lose more than you'll gain here,
> performance-wise.
>
> Why do you care to consolidate all of those reverse zones? If you're
> maintaining the data in those zones automatically via Dynamic Update from
> your
> DHCP server, then it shouldn't really matter whether they are separate
> zones
> or all one zone.
>
> - Kevin
>
> Hannah O Day wrote:
>
> > I have both dhcp and ddns servers (BIND4.93) that run on Aix boxes.  I
> have
> > been config all reverse zones on the per class C subnet basis.  I'm now
> > upgrade the server to BIND8.2.3.  I want to config the reverse with only
> > one class B instead of many class Cs.  Could anyone tell me if this will
> > cause any performance issues since the updates will now happen to the
> > entire class B instead of class c?





More information about the bind-users mailing list