Hi,
NSD 4.1.9 is available:
http://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.9.tar.gz
sha1 6ff4b2998aedf3a8ae18a071f1d121f3586aaf70
sha256 b811224d635331de741f1723aefc41adda0a0a3a499ec310aa01dd3b4b95c8f2
pgp http://www.nlnetlabs.nl/downloads/nsd/nsd-4.1.9.tar.gz.asc
Fix crash on startup when upgrading from 4.1.x to 4.1.8, because of
nsd.db format change. This has no effect if nsd.db is deleted before
upgrade or if database: "" is set in nsd.conf.
4.1.9
Thanks!
Paul
Hi Wouter,
Thanks for this! We were affected by this issue as well, because some
of our servers were still using the DB mode.
However, I have changed our internal SPEC file to build NSD with:
- --with-dbfile=""
so that all our NSD instances will use plain text zone files by
default, and simply not use the DB mode.
FYI for all NSD users. Wouter added this "nodb" mode at our request,
and it works really well for us. An NSD server that has only slave
zones will XFR them all in at startup. Periodically (default every
1h), it will flush the zones to plain text files on disk, so that when
NSD is restarted, it can read the zones back in. If 1 hour seems too
long to wait before writing out changed zones to disk, one can adjust
the value in nsd.conf.
In the event of a restart with unflushed zones, NSD will just read an
older copy of the zone from disk, and then immediately XFR a new copy
in. If you wish, you can also run "nsd-control write" before
restarting NSD, so that it restarts with the freshest copy of zones.
In my opinion though, all this isn't really necessary, because
restarts are rare, and if the odd zone here or there hadn't been
flushed to disk, it will be updated to the latest copy within moments
of starting NSD.
I can highly recommend the "nodb" mode by setting "database:" to "" in
nsd.conf, or making this the default at compile time with the
configure option I mentioned above.
Regards,
Anand Buddhdev
RIPE NCC
I would echo Anands endorsement of the nodb mode we use this for all of our TLD secondaries and have found it very efficient and stable.
Brett
We're using this as the OpenBSD default too (after I ran into some
problems with the dbfiles before, which I suspect may possibly have
been related to lack of cache coherency between mmap and file access
on OpenBSD).
I was initially uncertain if switching to "nodb" mode might
introduce performance problems during restarts but it has been
absolutely fine.
Brett Carr writes:
>
> I would echo Anands endorsement of the nodb mode we use this for all of =
> our TLD secondaries and have found it very efficient and stable.
This discussion raises the question whether we should make this the
default and havng the database optional (for backward compatibilaty).
jaap
Yes, I would like this very much! Many +1's for this change.
Anand
: Brett Carr writes:
:
: >
: > I would echo Anands endorsement of the nodb mode we use this for all of =
: > our TLD secondaries and have found it very efficient and stable.
:
:This discussion raises the question whether we should make this the
:default and havng the database optional (for backward compatibilaty).
:
: jaap
Additionally, what is the benefit of the database? If this is being
disabled at both the largest sites, and being disabled in standard
distributions, and is somewhat.....fragile, why continue shipping it?
Generally I would say yes this would be a good call however I am always cautious about changing the defaults in software that is important and that people rely on. Not everybody reads mailing lists or software release notes before upgrading, I’d like to think that everybody tests all software before it is changed (we certainly do) however I have worked places where this definitely does not happen. If the default changes then it needs to do this in a seamless manner and it needs to be very clear in the release notes and documentation.
Brett
And the version number too. These kind of changes warrant a minor
version change (i.e. bump to 4.2.x).
I remember a few years ago there was a similar undocumented nsd db
format change that bit lots of people when code hit production sites.
Back then using the db was not optional like today. Changes like that
should not be handled lightly.
Regards,
Tom
Point taken. Hopefully though the configure option is recommended in a README file until a new major version is released.
I have found the "db" mode very efficient and stable, too. What problems is it that the nodb mode fixes for you?
Ask
Hi Ask,
I have found the "db" mode very efficient and stable, too. What
problems is it that the nodb mode fixes for you?
For a start, the "nodb" mode uses less RAM. On our servers, RAM usage
dropped by about 8 GB, so this is rather significant.
As others have mentioned, the .db file is susceptible to corruption, and
can prevent NSD from starting altogether.
These two items are quite significant, and make a good case for the
"nodb" mode.
Regards,
Anand