Hi,
NSD 4.1.14rc1 maintainers prerelease is available:
https://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.14rc1.tar.gz
sha256 2917e247512a189169e056c638646c3e6d95b11545565639e3b93886dc69a571
pgp https://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.14rc1.tar.gz.asc
This version performs less zone transfer attempts, reducing load on the
server. The xfrd state file has a new version number, to store the
information. The new version of the file is written on exit of the daemon.
4.1.14
compiled on Debian Jessie, 32+64 bit (without /any/ warning)
installed on some hosts in my testlab...
Andreas
Hi Wouter,
NSD 4.1.14rc1 maintainers prerelease is available:
I've built internal packages of this for CentOS 6 and 7, and it appears
to work correctly on our test server.
Regards,
Anand Buddhdev
RIPE NCC
Hi,
NSD 4.1.14 is available:
https://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.14.tar.gz
sha256 bdfc61c5f3bf11febd8f4776eef1d4f2d95ed70f12f11d4eeee943c186ffd802
pgp https://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.14.tar.gz.asc
This version performs less zone transfer attempts, reducing load on the
server. The xfrd state file has a new version number, to store the
information. The new version of the file is written on exit of the daemon.
4.1.14
Hello,
I run a root server mirror like described in https://tools.ietf.org/html/rfc7706#appendix-B.2
on a ipv6 only host. Not sure if the behavior is new but just noticed it:
Initial I start without a local "zonefile", without a database ( nsd.conf has database: "" )
and also removed xfrdfile.
I expect nsd /immediately/ start fetching the zone from a master. But sometimes it take 2 minutes:
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.228.79.201 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.33.4.12 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.5.5.241 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.112.36.4 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 193.0.14.129 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.0.47.132 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10264]: xfrd: connect 192.0.32.132 failed: Network is unreachable
Dec 8 20:31:55 dns nsd[10305]: nsd started (NSD 4.1.14), pid 10264
Dec 8 20:33:55 dns nsd[10264]: xfrd: zone . written received XFR packet from 2001:500:2f::f with serial 2016120801 to disk
Dec 8 20:33:55 dns nsd[10264]: xfrd: zone . written received XFR packet from 2001:500:2f::f with serial 2016120801 to disk
Dec 8 20:33:55 dns nsd[10264]: xfrd: zone . written received XFR packet from 2001:500:2f::f with serial 2016120801 to disk
Dec 8 20:33:55 dns nsd[10264]: xfrd: zone . written received XFR packet from 2001:500:2f::f with serial 2016120801 to disk
Dec 8 20:33:55 dns nsd[10264]: xfrd: zone . written received XFR packet from 2001:500:2f::f with serial 2016120801 to disk
...
Dec 8 20:33:57 dns nsd[10264]: xfrd: zone . committed "received update to serial 2016120801 at 2016-12-08T20:33:57 from 2001:500:2f::f"
Dec 8 20:33:57 dns nsd[10305]: zone . received update to serial 2016120801 at 2016-12-08T20:33:57 from 2001:500:2f::f of 1309648 bytes in 1.39327 seconds
The next time I start with "empty" nsd, it try via ipv6 first and operate as expected.
Is there any preference or a missing selection on the protocol used for zone transfer?
Andreas
Hi Andreas,
NSD tries the masters in the order you listed them in the config file.
If you list all the IPv4 first, and it is an IPv6-only server, I
guess that makes it slow.
Because initially the network is down, it'll do exponential backoff on
retries. That explains the wait time.
NSD actually throttles fetching the zones, and does not do that
immediately after you start it. It inserts short delays.
Best regards, Wouter
W.C.A. Wijngaards:
Hello Wouter,
NSD tries the masters in the order you listed them in the config file.
If you list all the IPv4 first, and it is an IPv6-only server, I
guess that makes it slow.
yes, I arranged the master server list in a different order and nsd behave different.
Because initially the network is down, it'll do exponential backoff on
retries. That explains the wait time.NSD actually throttles fetching the zones, and does not do that
immediately after you start it. It inserts short delays.
The two minutes for the first, cold start ¹) I mentioned, are a tcp_timeout!
Looks like (my?) nsd instance cannot axfr from b.root-servers.net[2001:500:84::b]
which happen to be the first in my list.
Changing the order again let nsd fetch the root zone immediately after a cold start.
Everything is fine now.
Thanks,
Andreas
¹) cold start
- no database file
- no zone file written to disk
- no xfrd.state file