BIND 9.6 - IXFR to slaves not working after manual zone edit.

[Pete McNeil]

Hi folks,

According to DNS and BIND (the book) and other sources, BIND from 9.3 on 
is able to calculate differences for a zone file that is manually edited 
by using the following methodology:

rndc freeze <zone>
perform-updates-on-the-zone-file
rndc thaw <zone>

http://books.google.com/books?id=HggtWI1ShvMC&pg=PT263&dq=%22this+means+you+can+now+%28or+again%29+edit+zone+datafiles+manually.%22&cd=1#v=onepage&q=&f=false

All servers have "ixfr-from-differences yes;" appears in options { } on 
the master and slave servers.

I have created a script that does what is specified. The 
perform-updates-on-the-zone-file part of the process reads a list of IPs 
from a proprietary database and recreates the zone file. The result is 
the same zone file with a new serial number and some changes in the IPs 
that are include (A records for a blocking list). The rest of the file 
appears unchanged. This is as if the file had been edited by hand to 
change a few of the A records and update the serial number with no other 
changes.

I am performing this operation on an RHEL 5 server using the an RPM from 
FC including BIND 9.6.1. BIND (named) is running chrooted.

The zone file is located in /var/named/chroot/var/named/dynamic so that 
named can write to it and create the .jnl file.

The design of the system is for this server to calculate the differences 
and then provide the changes to slave servers vi IXFR for delivery to 
end user systems etc.

The problem:

With each update the entire zone is being retransmitted via AXFR. Since 
this is on the order of 2 - 5 million A records where only a handfull 
will have changed between updates (about 10 minutes apart) -- AXFR is 
_NOT_ desired.

Additional symptoms:

BIND appears to be unable to see the .jnl file after it is successfully 
created. It complains at each update that the .jnl file does not exist 
and then recreates it. However it is clear that the .jnl file _does_ 
exist and has the correct permissions for named to see it.


Log says:

journal file /var/named/dynamic/blacklist.example.com.zone.jnl does not 
exist, creating it

However ls says:

[root at server etc]# ls -l /var/named/chroot/var/named/dynamic
total 56704
-rwxrwx--- 1 named named 57852592 Jan 21 20:11 blacklist.example.com.zone
-rw-r--r-- 1 named named   141770 Jan 21 20:12 
blacklist.example.com.zone.jnl

Additional info:

The master and slave servers are using the same version of BIND in the 
same configuration. The slave servers are working correctly as a 
resolver farm and have been for quite some time. Once transferred 
queries to the zone work as expected. The problem is strictly how the 
transfers are done.

As an experiment I tried using nsupdate to change a single record at a 
time in the zone. Each time I changed a single record the slaves were 
notified and performed a full download of the zone again via AXFR.

Anyone have any idea what's going on?
Why doesn't IXFR work as specified?
Why does BIND complain that the .jnl file for the zone does not exsit 
when it is clearly visible?
Why does a single record change via nsupdate also cause a full zone 
transfer to slaves?

Thanks in advance!

_M