Strange problem

[Kevin Darcy]

Jean-François Leroux wrote:
> Hi,
> I'm running bind 9.3.4.2 on four debian etch servers.
> Here's the setup :
> Two servers are in a private network, server1 is primary master and server3
> is the slave, two are in an external network, server2 is slave of server1
> above and master for  server4 (which is the external slave).
> All updates of zones are made on server1, and propagated to the other
> servers via a TSIG authentication, following this scheme : S1 sends notify
> to S3 and S2. Then S2 notifies S4.
> The problem : for one of my zones (I have several), S4 doesn't update
> correctly. For example, if I increment the serial and comment out a dns
> record, then issue a /etc/init.d/bind9 restart, S2 and S3 update correctly
> but S4 is one update late, eg it is 20070518O1 instead of 2007051802, and so
> on 02 instead of 03, 03 instead of 04...
>
> The only way to get it working is restart bind from S1 TWICE, which is
> rather unexpected. For my other zones everything runs well with one restart
> only.
>
> Of course, there are no error messages. S2 sends notify to S4, S4 says 'zone
> is up to date', but doesn't  update.
>   
Slaves don't tell masters that their zones are up to date. What 
*exactly* is the response from S4 to S2 for the NOTIFY? If it's REFUSED, 
then that means S4 isn't accepting the NOTIFY because it doesn't 
recognize S2 as a master for the zone. This might be because S2 is 
multi-homed and is sending the NOTIFY from a different source address 
from that which appears in the masters clause. You can fix that with a 
notify-source on the master side, or an allow-notify on the slave side.

*If* a slave accepts a NOTIFY from one of its known masters, *then* it 
does a "refresh" query to see if its version of the zone is up to date, 
and only *then* will it initiate a zone transfer if it thinks it needs 
one. Zone transfers are subject to quota limits, so it's possible on a 
busy server that it might take a while for the zone transfer to take place.

Also, how are you determining that S4 isn't fully up to date? Are you 
looking at the zone file or actually querying the server? It's possible 
that the changes aren't being committed immediately to the zone file...

                                                                         
                     - Kevin