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

[Constantin Stefanov]

On 17.03.2015 18:32, /dev/rob0 wrote:
> On Tue, Mar 17, 2015 at 05:36:57PM +0300, Constantin Stefanov wrote:
>> After upgrading from BIND 4.6 to 4.10.2, named requires that 
>> different slave zone have separate file for cache.
> 
> Surely you mean s/4/9/g, and yes, this is true.
Of course, sorry.

>> With 4.6 I had the following config:
>>
>> named.conf:
>>
>> view "internal" {
>> 	match /* match condition */;
>> 	include "common.zones";
>> };
>>
>> view "external" {
>> 	match /* match condition */;
>> 	include "common.zones";
>> };
>>
>> common.zones:
>>
>> zone "aaa.example.org" {
>> 	type slave;
>> 	file "slave/aaa.example.org";
>> 	masters {MASTERIP;};
>> };
>>
>> It worked fine with 4.6 (although it was considered incorrect).
>>
>> After upgrade to 4.10 named started complaining:
>>
>> common.zones:3: writeable file 'slave/aaa.example.org': already in 
>> use: common.zones:3
>>
>> As I understand, now I need to have separate files for different 
>> views.
>>
>> But is there a way to have them automatically assigned and to write
>> something like:
>>
>> file "slave/aaa.example.org.${view_name}"
>>
>> or any other way to have only one defininition for common zones?
> 
> Here is an easy suggestion:
> 
> view "common" {
> 	match-clients { none; };
> 
> 	zone "example.com" {
> 		type slave;
> 		file "common/example.com";
> 		masters { example.com-masters; };
> 	};
> 	// repeat for other common zones
> };
> 
> And then your other views can be defined and use the include file as 
> before, with each zone being:
> 
> 	in-view "common";
> 
>> I found 'in-view' option, but again it requires two definitions for 
>> every zone: one with "file" and "masters" directives, and another 
>> with "in-view" option. Moreover, these two definitions must be in 
>> different files, as I have to include one in first view, and 
>> another (with 'in-view') in all other views, so I have to keep two 
>> separate files synced with one another.
>>
>> So is it possible to have only one definition for slave zones that 
>> are shared between different views?
> 
> Hmmm.  I am not sure if there is a good workaround for that.  But 
> there are tools like make(1) which can do this for you?  I would 
> suggest a script to generate the common.zones file from whatever 
> you're using for the "common" view.
> 
> Maybe someone else will have a better suggestion?
Well, using make and scripting is certainly an option, but not having to
use it is better in my opinion. And as I said in another letter, with
9.6 there was no need for scripting.

I do not generate "common.zones", I write it by hand. And now I have to
make a script that generates another "common.zones.internal" from
previous "common.zones" or generate them both from comon source.

I any case it is unnecessary (in my view) complication caused by
upgrade, I would call it a regression, as I used this config for at
least five years, and now I have to invent something.

So I am asking for better solution, too. But reading docs and googling
did not give me a clue.

-- 
Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University