It would be nice if we could add the line allow-notify: 127.0.0.1 NOKEY to the server: section instead of in each zone: section. Especially, since it is a requirement for nsdc update. Or even make it implicit to always allow this from localhost (f you can't trust localhost, you have more problems) Paul
On Fri, 14 Sep 2007, Paul Wouters wrote: Upgrading to nsd-3 on a production server, I noticed: Sep 14 12:52:51 ns0 nsd[25801]: could not open file /etc/nsd/ixfr.db for append: Permission denied Checking the original configure script, I also noticed the setting for xfrd.state is located in /etc/nsd/. Since in normal setups, nsd drops permissions from root to nsd, and the user nsd should not be allowed to write configuration files in /etc/nsd for security reasons, this is not an ideal default. Also, these files are not configuration files, but state files, and should really be located in /var/lib/nsd or /var/cache/nsd. This would then also make it play better with technologies like SElinux. I've changed the Fedora spec file to place the files in those directories, but its worth considering changing the defaults in the configure script as well. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Paul, Thanks for your feedback! Paul Wouters wrote:> It would be nice if we could add the line > > allow-notify: 127.0.0.1 NOKEY > > to the server: section instead of in each zone: section. Especially, since > it is a requirement for nsdc update.We understand how this would make your life "easier". On the other hand this is not something that is impossible without changing NSD. In general we prefer not to add functionality that makes the config file simpler. It creates more code in NSD (and we have the risk that we end up creating a full language parser for the config file). So for advanced config file management we could say use an external macro preprocessor. The good news is that in this case we consider to create a flag with limited functionality. We could create a flag in the "server" section, "allow-localhost-notify" that turns allowing notifies from localhost on. We will discuss this a bit more internally and let you know what the concensus is.> Or even make it implicit to always > allow this from localhost (f you can't trust localhost, you have more > problems)For security reasons, and no really good reasons in favour of it, we won't make it trust localhost by default. Regards, Mark - -- Mark Santcroos NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG75Zovgq6Qtvn644RAtzUAKCgPEdiZjwMCKRYxa6cAA75NEXuKACguxQG FHCSUFyJD8Y5QazDvOY+lRQ=vkFA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Not replying to one message in particular. In this thread we learned that people are still using nsd-notify directly, or indirectly via "nsdc update". As mentioned in the release notes of NSD 3.0.0 NSD now has all this functionality build in. Therefore we at that time deprecated nsd-notify and planned to remove it in the future. So we are eager to find out why people are still using it, to see whether there are good reasons to keep it or to possibly make life easier for users. Thanks for your response in advance! Regards, Mark - -- Mark Santcroos NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG858rvgq6Qtvn644RApY3AKC0eQLn9hM09WksLIq+v9W5d9MRoQCgo3ii MlFOnkmhDc64gLgpWAUFIVk=L57K -----END PGP SIGNATURE-----