BIND 8.2.7 master ixfr to 9.2.2 slave

[Mike Mitchell]

Mayer () gis ! Net writes:

> Don't use IXFR on BIND 8. It never quite worked right and it got
> rewritten
> 3 times. It works correctly in BIND 9.

> Danny

That response is similar to

Patient:  Doctor, it hurts when I do this.
Doctor:   Don't do it.

I'll admit that their might be bugs in BIND 8's implementation
of IXFR, but they shouldn't cause BIND 9 to blow away it's zone
information.  This smells like a small bug in BIND 8 tickling
a large bug in BIND 9.

I've diff'd the bin/named/ns_ixfr.c and bin/named/ns_xfr.c code
between 8.2.7 and 8.4.6 and the only change of significance I
saw was the code sequence "db_freedata(rp->r_dp); rp->r_dp =3D NULL;"
in 8.2.7 was replaced in 8.4.6 with "db_detach(&rp->r_dp);".
"db_detach()" maintains a reference count to the data and calls
"db_freedata()" when the count reaches zero.  It also sets the
pointer to NULL, so it's equivalent to the old "db_freedata(rp->rdp);
rp->rdp =3D NULL;" sequence.

The other changes are minor portability changes and support for IPv6,
With the exception of the bug fix for bug #1490.  That bug fix
(which I wrote) only affects truncating the IXFR log when it
exceeds maximum size, not responding to IXFR requests.

It looks to me like the bug in 8.2.7 (if there is one) is still
present in 8.4.6, and would therefore affect bind 9.2.2 slaves.
My question is if the bug in 9.2.2 has been fixed in 9.2.5.

Mike Mitchell
Mike.Mitchell at sas.com