BIND 9.6 - IXFR to slaves not working after manual zone edit.
Pete McNeil
madscientist at microneil.com
Fri Jan 22 01:26:23 UTC 2010
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
More information about the bind-users
mailing list