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.
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).
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.
I will retry this step by step...
(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).
Thanks,
that clarify the errors.
But wouldn't it be better to log a warning at the slave?
Optional (configuration?) the slave could continue to fetch the zone
to avoid such errors at the server. Optional, that really depend on the zone size.
Anyway: the errors are really confusing and should not occur if a nsd talks to a nsd.
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.
after $DISABLE_SSLv3_ANYWHERE I had some to look at my nsd servers.
I did it exactly like suggested but no notify.
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.
after $DISABLE_SSLv3_ANYWHERE I had some to look at my nsd
servers. I did it exactly like suggested but no notify.
This should so have worked, but it didn't work for you. It all looks
fine, just this one config line:
allow-notify: 2001:db8::1/128 NOKEY
The /128 is not necessary, and is that a corner case issue with
config? (just state the IP address without /netblocksize and it picks
it as a single address).
With verbosity 5 it may print more (i.e. sending notify), or tcpdump
to see which server is the problem (i.e. are notifies sent and not
received?)
This should so have worked, but it didn't work for you. It all looks
fine, just this one config line:
allow-notify: 2001:db8::1/128 NOKEY
The /128 is not necessary, and is that a corner case issue with
config? (just state the IP address without /netblocksize and it picks
it as a single address).
good point, I corrected this.
With verbosity 5 it may print more (i.e. sending notify), or tcpdump
to see which server is the problem (i.e. are notifies sent and not
received?)
I setup a testbed and could prove that master+slave work
in ipv4 only as well as ipv6 only configurations.