content-type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-RT-Original-Encoding: utf-8
Content-Length: 2126

Hello Evan,

I made some fixes to original patch, because I think it does not allow
simple upgrade from older versions without manual configuration change.
I would like default configuration with custom directory for nzf files.
It would be difficult to do that, if user could have his own zones added
in customized configuration. Also it contains fix for a case, when
option is not even in configuration file. Sorry I did not test it out
before.

I made also very simple addition to addzone tests. It helped me to find
some errors.


Now back to your question. We have got such configuration for a long
time. It was not something I invented, but I think it makes sense. We
have got master zone files in home /var/named directory. These are files
that are managed by an administrator (or packaging system). He is
changing them using editor or his tools. He "owns" them somehow. Named
is allowed only to read them, serve them as they are.

For dynamic zones, that are modified primarily by named, are there
prepared sub folders dynamic and slaves. Files there are "owned" by
named and no one should edit them, unless he makes sure named is not
touching them.
It increases security a bit I think. Especially when it is enforced by
SELinux, not only simple unix rights. It helps administrator to
distinguish what can be modified by bind and what cannot.

I think there are only dynamic zones with their journal. But they use
temporary files in the same directory as themselves, aren't they?
What other problems can it make? I can think only automatic DNSSEC
resigning. Such zones are updated using dynamic updates anyway, aren't
they? Selinux will log any access violation. The only problem reported
by users was .nzf files. If you know any potential problems, I would
really like to hear them.

Best Regards,
Petr Menšík

Dne 10.3.2017 v 18:46 Evan Hunt via RT napsal(a):
> Thank you for the patch, we'll review it. If it makes sense for
> managed-keys then it makes just as much sense for this.
> 
> I'm curious why you're using a non-writable working directory,
> though?  That will cause more problems than just this.
> 
>