managed-keys.bind's directory problem

Chris Buxton cbuxton at
Mon Dec 14 18:14:01 UTC 2009

On Dec 13, 2009, at 5:40 PM, Doug Barton wrote:
> On Fri, 11 Dec 2009, Mark Andrews wrote:
> To repeat my primary objection, if the named user can write to the configuration directory it can change the contents of named.conf. That's a security problem.\

So don't put named.conf inside the working directory. Put it in /etc, or something like that.

	(working directory)

You are not bound to put anything into the working directory. Just make sure it's writable by named. However, this is a convenient place to put zone files, as long as you don't mind giving named permission to rewrite/overwrite them.

Of course, the paths above can be prefixed with a chroot directory path.

>> On some OS's this is the only way to get a core file for debugging as there is no way to specify anything other than the current working directory.
> Once again, I assert that this is a design flaw in named. Processes should not be dumping random stuff into the same directory where their configuration files go. It may have been acceptable back in the BIND 4 days, but it's time to move on.

Yes, it's time for you to move on. Don't put anything that should not be writable in or under the working directory. Start using absolute paths instead of just filenames.

The options { directory ""; }; statement specifies named's working directory (its 'cwd'), not the location of the configuration directory.

Chris Buxton
Professional Services
Men & Mice

More information about the bind-users mailing list