Strange problem

[Jean-François Leroux]

Thanks for your answer, Kevin.
I reinstalled bind9 and it works now (actually I reinstalled previous 9.3.2,
then updated to 9.4.3). Don't know what happened.
Just for the record, the message from S4 was: 'zone is up to date', as when
the server is functioning correctly, but zone wasn't since it's serial was
one increment late...
However, from what you said I'm wondering about something:

I noticed in my named.conf.local that S3 notifies S2 and S4 too (the two
external dns servers). Since S1 already notifies S2, is there a risk of
trouble because of this duplicated notify from S1 and S3?

cheers.



2007/5/19, Kevin Darcy <kcd at daimlerchrysler.com>:
>
> 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
>
>
>