Hi Evan,

today I was checking my 9.11 instance with some stuff of dyndb. I
noticed write errors of NTA files. I did not notice it before, because I
do not use Bind 9.11 much yet. I am sure I would like to be able to
change view->nta_file write directory as well. It is less important than
nzf files for me right now.

I do not like an idea of three options however, all of them with the
same value. I think it would make sense to have one common option for
all mkeys, nzf/nzd and nta files. With possible override for a specific
type if required.

It might be useful to have configuration type of "path to existing
directory" maybe. It would not be required to copy path test and report
and error in case specified directory did not exist.

I am looking forward to merge back your changes. I will try to make
similar backport to Bind 9.9 which we ship in RHEL.

You are right about core dumps. We have coredumps handled by abrt tool
in Fedora and RHEL. Without manual configuration, you will not get core
dump in working directory in those distributions. Maybe also from
derived ones. They are dumped into some system directory, where they are
unreadable by ordinary user. That is important feature of packaged
services, because it allows easier sending of core dumps (and more
information) from our customers. Unfortunately most bugs from BIND are
core dumps from memory leak detection, where I am not able to tell the
reason for them. But it is good feature anyway.

Dne 25.3.2017 v 07:28 Evan Hunt via RT napsal(a):
> 
>> 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.
> 
> The most significant problem that's hard to correct with careful configuration
> of named is that most platforms write core dumps to the working directory by
> default, and changing that is usually a system-wide setting rather than something
> that can be corrected specifically for named. It makes for difficult
> debugging.
> 
> But I do think you're correct that the files named has direct control over can
> be configured to write elsewhere (with the exception of NZF and NZDB files,
> which your patch addresses).
>