[nsd-users] nsd as master + slave

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas,


On 09/10/14 23:25, A. Schulze wrote:
> hello,
> 
> I configured nsd-4.1.0 as master + slave. communication is forced
> via ipv6.

Are you trying to force updates without incrementing the SOA serial
number?  NSD expects you normally to increment the SOA serial number,
then reload the zone into the master, which then sends a notify with
this serial number to the slave which then fetches the zone.

Without an increment of the serial number, you have to, indeed, delete
the database or use nsd-control force_transfer (at the slave) to force
a zone transfer.  Notifies won't work because the slave server thinks
it has the correct serial number.

So, increment (+1) the serial number of the SOA in the zonefile on
disk.  At the master perform nsd-control reload.  That will read in
the zonefile, and start sending notifies, and the slave then fetches
the zone.  The manual transfer and notify commands are for control in
case of operational difficulties, just a reload on the master of the
zone should work.

(the connection resets are because you shortened the SOA timer values
significantly and the slave is indeed attempting to fetch the zone,
but aborts the zone transfer as soon as it figures out you did not
change the SOA serial number).

Best regards,
   Wouter

> @master zone: name: "example.org." zonefile: "/path/to/zonefile" 
> outgoing-interface: 2001:0db8::1:1 notify-retry: 5 notify:
> 2001:0db8::2:1 NOKEY provide-xfr: 2001:0db8::2:1 NOKEY
> 
> @slave zone: name: "example.org." allow-notify: 2001:0db8::1:1
> NOKEY request-xfr: 2001:0db8::1:1 NOKEY
> 
> As the slave has not "zonefile" statement I could remove nsd.db
> and restart nsd to force the slave fetch data from master. that
> works. I could also build a newer zone on the master and run
> "nsd-control transfer" at the slave. that work too.
> 
> But I would expect that a "nsd-control notify" at the master
> trigger a packet from master to slave to inform the slave about the
> current serial. I do not see any logging nor any packets
> transferred.
> 
> Q1: how do I notify a slave about a new serial to force a update 
> initiated by the slave?
> 
> For testing purposes I shortened the refresh and retry parameters
> in example.org SOA record. ( refresh 120s, retry 60s )
> 
> Now the slave initiate a tcp connection every 120s and trigger
> this logging at the master: [2014-10-09 22:57:18.247] nsd[25239]:
> error: failed reading from 2001:db8::2:1 tcp: Connection reset by
> peer [2014-10-09 22:59:11.215] nsd[25239]: error: failed reading
> from 2001:db8::2:1 tcp: Connection reset by peer [2014-10-09
> 23:01:00.909] nsd[25239]: error: failed reading from 2001:db8::2:1
> tcp: Connection reset by peer [2014-10-09 23:02:57.600] nsd[25239]:
> error: failed reading from 2001:db8::2:1 tcp: Connection reset by
> peer [2014-10-09 23:04:53.284] nsd[25239]: error: failed reading
> from 2001:db8::2:1 tcp: Connection reset by peer
> 
> I did a tcpdump and saw that (at least a significant part of) the
> zone is transferred via tcp. Finally the slave sent tcp reset
> packets. I could provide dumps.
> 
> Q2: Do I something completely wrong?
> 
> Thanks, Andreas
> 
> 
> 
> 
> _______________________________________________ nsd-users mailing
> list nsd-users at NLnetLabs.nl 
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUN4fQAAoJEJ9vHC1+BF+NOgsQALB9Vscxr2ZZ9Y6yHpSFBbmz
QcOgLAMNrYpqZ7KIar8IgKiKWpGyP91mSpg+K+1sZEr7d2ohzdnZDmA1hEQIya9C
5mBuYh4apSW2DgIPWCMJUkc2K3W9eJig2KecWyot7KBq8ggS2DUuJpzSjsCKVL9I
7hgrCGE3oFg1Imae4o4W7N2GD5iG8KCyBxoZ2fIOw1ZPOXWi4KXGaV4TE2Q9ApVo
Mur7fSM1TlHeAtEtTu8OrFDNs3JQ7MjzYa/x4O6dRRaRLn8RefW7gKJECsz1Nkv1
YgDzDXhKYRkFyoHJf4t3EVF3cVo9VRB15MnWbM1psNEaOZxrX7OzPQX9yZ9S/mZu
R2CoBYXC76V1d35qtvt7nRfxYX1K/HwmCDr3uWPP8UZtB+tKbcJCX2svuGbrHylG
j2tm/1MX+oz9ORPBsFNmV0WrddzbKra/9LMsFsJ/ws6OXd5KtXR0l8tdxqbIP/M1
70FVsobnh1SQatfbyu1SyU/qWMZ9jN/SbPAwZAENL8yqMGfxh+5ViqjkWAYBsQoa
yVJA2cBrkmCfk3rI5cqDARMfUwg9aDEJh5DLmXn81R45pptoMHwHMPPtOqC6hxgh
6E3WIHSC0MXhuglmUmg3K9PPAgnBfYJOLo7jtmZosg3unMI3oscg5/HlQe4pLokS
dYpCEKYW1oIVyGU2pvHu
=2xJJ
-----END PGP SIGNATURE-----