Created attachment 168253 [details] update nsd to 4.1.9 update dns/nsd to 4.1.9 Changelog: BUG FIXES: - Change the nsd.db file version because of nanosecond precision fix.
Comment on attachment 168253 [details] update nsd to 4.1.9 Yes, go ahead
A commit references this bug: Author: ohauer Date: Tue Mar 15 19:56:28 UTC 2016 New revision: 411202 URL: https://svnweb.freebsd.org/changeset/ports/411202 Log: - update to 4.1.9 BUG FIXES: - Change the nsd.db file version because of nanosecond precision fix. Approved by: jaap@NLnetLabs.nl (maintainer) PR: 208043 MFH: 2016Q1 Changes: head/dns/nsd/Makefile head/dns/nsd/distinfo
A commit references this bug: Author: ohauer Date: Tue Mar 15 20:00:45 UTC 2016 New revision: 411203 URL: https://svnweb.freebsd.org/changeset/ports/411203 Log: MFH: r411202 - update to 4.1.9 BUG FIXES: - Change the nsd.db file version because of nanosecond precision fix. Approved by: jaap@NLnetLabs.nl (maintainer) PR: 208043 Approved by: ports-secteam (implicit) Changes: _U branches/2016Q1/ branches/2016Q1/dns/nsd/Makefile branches/2016Q1/dns/nsd/distinfo
Created attachment 168256 [details] suggestion for next update to 4.1.10 Hi Jaap, after reading the discussion about the nsd.db concern on the mailing list I got the idea to handle this in the FreeBSD rc-script. Don't know if it is really bullet proof, but if you like it maybe submit the patch with the next nsd update.
(In reply to Olli Hauer from comment #4) That is a nice idea. Drawback is that it slows down the halting/rebooting of the machine when there are zillions of zone files to write and/or the database is big. > Don't know if it is really bullet proof, but if you like it maybe > submit the patch with the next nsd update. The corner case is that when the machine crashes (during the rites) the files might be corrupted. But as far as I know, corrupt files are automatically recreated in this case (the recent problem was due to a programming error). But yes, having an better-save-then-sorry-on-exit might be fine.
(In reply to jaap from comment #5) > Drawback is that it slows down the halting/rebooting of the machine when > there are zillions of zone files to write and/or the database is big. For this case we can add a parmeter like nsd_woe (write on exit) or similar. > The corner case is that when the machine crashes (during the rites) > the files might be corrupted. Good argument, especial in case of a system hang. Perhaps I can find the time to do some empirical testing with a bigger amount of generated zone files ;)