nsd users - May 2015 - Synchronizing zone serial #s across zone transfers?

I have NSD4 slaved as sceondary to a Bind9 primary.

If I incement a zone file's serial on the bind9 server

	grep -i serial /var/chroot/named/namedb/master/MYDOMAIN.com.zone
		1433012338    ; Serial, Timestamp: [ 2015.05.30 11:58:58 ]

	( increment serial )
	rnds reload
	grep -i serial /var/chroot/named/namedb/master/MYDOMAIN.com.zone
		1433012595    ; Serial, Timestamp: [ 2015.05.30 12:3:15 ]

and monitor logs @ nsd4

	[2015-05-30 18:59:00.038] nsd[30991]: info: zone MYDOMAIN.com serial 1432943027
is updated to 1433011794.

notice that the 'new' serials do NOT correspond for the zone @ primary
& secondary.

	@ bind9:  1433012595
	@ nsd4:   1433011794

Iiuc, they're supposed to.

What do I need to do to fix this lack of correspondence?

Bob

> What do I need to do to fix this lack of correspondence?
If after this 'un-syncd' transfer I MANUALLY restart the nsd4 secondary,
then it updates its local zone files to the serial #s sent by the bind9 primary.

Is there any additional command I need to send, or config parameter in
nsd4.conf, to force the update?  Or do I have to restart nsd4 each time ?

Bob

On 30/05/15 21:14, robert.devanna at nospammail.net wrote:
> I have NSD4 slaved as sceondary to a Bind9 primary.
> 
> If I incement a zone file's serial on the bind9 server
> 
> 	grep -i serial /var/chroot/named/namedb/master/MYDOMAIN.com.zone
> 		1433012338    ; Serial, Timestamp: [ 2015.05.30 11:58:58 ]
> 
> 	( increment serial )
> 	rnds reload
> 	grep -i serial /var/chroot/named/namedb/master/MYDOMAIN.com.zone
> 		1433012595    ; Serial, Timestamp: [ 2015.05.30 12:3:15 ]
> 
> and monitor logs @ nsd4
> 
> [2015-05-30 18:59:00.038] nsd[30991]: info: zone MYDOMAIN.com serial
> 1432943027 is updated to 1433011794.
> 
> notice that the 'new' serials do NOT correspond for the zone @
primary & secondary.
> 
> 	@ bind9:  1433012595
> 	@ nsd4:   1433011794
> 
> Iiuc, they're supposed to.
Is your BIND server configured to send a notify message to the NSD4
slave? Is the NSD4 slave actually configured to transfer zones from your
BIND primary?

Without seeing the configurations of both sides, it's hard to say if
there's any subtle error in either one of them causing this behaviour.

Anand