Bad zone content in transfers

[Kevin Darcy]

Are you using views on the master? This sure sounds like the classic 
"matching the wrong view" problem.

More generally, do you recognize the contents of the "wrong" version of 
the zone? I've never known BIND to simply fabricate zone data before. It 
must be getting the data from *somewhere*.

You could perhaps run a sniffer, e.g. tcpdump or snoop, to verify where 
the slave is getting the bad version of the zone.

                                                                         
                                                                        
   - Kevin


Kris wrote:

>Hi,
>
>I'm using a simple setup of master/backup BIND servers.
>I use transfers to apply changes from the master to the backup server
>(see config files excerpts below).
>
>When I do a manual change into one zone file on the master, I change
>the serial number from (ex.) 2005110115 to 2005112801 to force the
>transfer to the backup.
>On the backup server, the transfer starts and the zone file has correct
>date/time (logs are correct). The problem is that the file has not the
>same content, and the serial of that zone file is (ex.) 2005062412.
>I removed all the zone files on the backup server and forced new
>transfers for all zones, the zone files came, but the content is not
>good ! It's like the zone file comes from another server ... but there
>isn't, and I see in the logs that the transfers come from the master
>which has the good files. I neither have another default install of
>BIND or some stuff running on the master server.
>
>Did I miss something in the config ?
>Could you please help ?
>
>Thanks in advance,
>
>Kris.
>
>On the master (192.168.1.1) :
>
>options {
>        directory "/var/named";
>        dump-file "/var/named/cache_dump.db";
>        statistics-file "/var/named/named_stats.txt";
>        zone-statistics yes;
>        forwarders {
>                10.1.1.1;
>                10.1.1.2;
>        };
>        allow-transfer { 192.168.1.2; };
>        allow-query { internal-networks; 127.0.0.1;};
>        also-notify {192.168.1.2;};
>        notify yes;
>        // provide only full zone transfers
>        provide-ixfr no;
>};
>
>zone "blabla.example.com" in {
>        type master;
>        file "blabla.example.com.hosts";
>        allow-transfer { 192.168.1.2; };
>};
>
>
>On the backup (192.168.1.2) :
>
>options {
>        directory "/var/named";
>        dump-file "/var/named/cache_dump.db";
>        statistics-file "/var/named/named_stats.txt";
>        zone-statistics yes;
>        forwarders {
>                10.1.1.1;
>                10.1.1.2;
>                };
>        // allow notify from master server
>        allow-notify { 192.168.1.1; };
>        // this host cannot be a source for zone info
>        allow-transfer { none; };
>        // no changes should be made on this host, but
>        notify no;
>        allow-query { internal-networks; 127.0.0.1;};
>        transfers-per-ns 10;
>        forward only;
>        allow-recursion {internal-networks;127.0.0.1;};
>        minimal-responses yes;
>        recursion yes;
>        // request-ixfr no --> request only full zone transfers to
>master
>        request-ixfr no;
>};
>
>zone "blabla.example.com" in {
>        type slave;
>        masters { 192.168.1.1; };
>        file "bak.blabla.example.com.hosts";
>};
>
>
>
>
>
>  
>