Re: BIND 9.6 - IXFR to slaves not working after manual zone edit.
Mark Andrews wrote:
First of all,
Wow- That really cleared things up. I don't recall the documentation
saying any of that very clearly, so we were misled by what we did read.
The problem is solved now:
* Treating the zone on the master as completely normal.
... zone file in /var/named/chroot/var/named
... no allow-updates { } as that causes it to be dynamic
* The script simply reloads the zone
... not using rndc freeze / rndc thaw
... added benefit -- no need to chgrp the zone after writing it --
read-only is sufficient (script is run by root)
* The slaves no longer have ixfr-from-differences, the master does
-
I'm guessing that my experiment with dynamic updates using nsupdate
failed to produce IXFR because at the time the slaves also had
ixfr-from-differences. I haven't verified that guess - is it correct?
THANKS!
_M
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6 - IXFR to slaves not working after manual zone edit.
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=HggtWI1ShvMCpg=PT263dq=%22this+means+you+can+now+%28or+again%29+edit+zone+datafiles+manually.%22cd=1#v=onepageq=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:
[r...@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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 - IXFR to slaves not working after manual zone edit.
First of all, decide where you want the delta to be computed. On the master or on the slaves? Currently you are asking all servers to compute the delta. Secondly if you are not using dynamic update to modify the master zone you don't need to freeze the master zone as named is NOT writing to it. Just replace and reload will work. Thirdly rndc freeze removes the journal. Fourthly ixfr-from-differences forces the slave to make AXFR requests. Lastly, dynamic zones and ixfr-from-differences are currently mutually exclusive. This may or may not change in future releases. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
