Single slave zone definition for two view (cache file name problem)

Konstantin Stefanov cstef at
Wed Mar 18 14:10:29 UTC 2015

On 18.03.2015 16:55, Steven Carr wrote:
> On 18 March 2015 at 13:30, Konstantin Stefanov <cstef at> wrote:
>> It isn't. But maintaining one file is easier. And having to maintain two
>> after five years everything worked fine with one is annoying.
> This highlights the need for a test environment, don't apply untested
> updates to production systems, it'll help you avoid running into
> issues like this where something in the product has changed and then
> you're forced to cobble together an ad-hoc solution to "just fix it"
> on-the-fly.
Did I say it is happening in production? I think I didn't, because it is
a copy to test the upgrade, production is still running OK with 9.6.

>> Not all my zones are identical, but most, and there is quite a bunch of
>> them. The problem is that two files for identical zones can't be the
>> same as they used to be. They must differ in file names for slave zone
>> caches, or have 'in-view' directive. So simply copying does not work,
>> otherwise 'include' would work fine.
> Not sure whether BIND would detect this or not but what about using a
> hard link? Underlying file would be the same but filenames different
> (though with the caveat of "these should be read-only master zones, no
> DDNS, not a slave zone")
The issue is that named started to detect it since, if I'm not mistaken,
9.7. It happened because such config was leading to bugs, but instead of
fixing the bugs, the whole feature was prohibited.

Hardlinks is not a solution. I do not care about additional disk space,
what I care about is the need to have two configs with different file
names (again the case with hardlinks) instead of one as it was with 9.6

Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University

More information about the bind-users mailing list