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

Konstantin Stefanov cstef at parallel.ru
Wed Mar 18 15:11:56 UTC 2015



On 18.03.2015 17:41, /dev/rob0 wrote:
> On Wed, Mar 18, 2015 at 11:48:40AM +0300, Constantin Stefanov wrote:
>> I see why it may lead to problems.
>>
>> But in fact the configuration with only one writable file 
>> referenced several times is suported now. If I write:
>>
>> view "view1" {
>> 	zone "aaa.exampe.org" {
>> 		masters {IP;};
>> 		file "slave/aaa.exmaple.org";
>> 	};
>> };
>>
>> view "view2" {
>> 	zone "aaa.exampe.org" {
>> 		in-view "view1";
>> 	};
>> };
>>
>> then both views will refernce ther same writable file, won't they?
> 
> No.
> 
>> Or am I missing something about "in-view" directive?
> 
> Perhaps.  The view2 reads zone data from view1, which in turn reads 
> data from the file (and its journal.)  Notifies from the master are 
> directed to view1, which does the IXFR or AXFR and writes the 
And what if notify will arrive from host which is in view2? I just
wonder, I don't think there is really a bug.

> journal.  There is no shared access to a journal.
So in fact they both read from the same writable file. Yes, technically
only one write reference for the file is there, others are just reading,
but the result is the same: one writable file is used for one zone in
several views. Of course it is a much more simpler design for
developers, than to allow concurrent writes.

> 
>> And if I'm right, the only question is how to simplify the 
>> configuration so not to have two definitions in two files for
>> every slave zone which is shared between views.
> 
> I can think of two possible ways to do what you want, each using 
> multiple, separate files for each zone (one file/journal per view.)  
> I don't believe either way exists right now, but perhaps one of these 
> ideas would make a reasonable feature request.
> 
> The first way would be if a view could have its own "directory" 
> option set.  Then the relative paths in your example above would 
> point to different directories.  The ARM is not explicit as to 
> whether or not this is possible, but some simple experimentation 
> would quickly determine the answer.
I think ARM is quite explicit that directory is only allowed in
'options' clause. But to be sure I tried to put 'directory' into view
and got an error
unknown option 'directory'


> The second way definitely does NOT exist, and that would be to have 
> some kind of variable in the named.conf syntax to refer to the name 
> of the current view.
I thought of the same options, if you look at my message Matus UHLAR
(and the second suggestion was in my message which started the thread).
But I do not have needed skills to implement it myself.


-- 
Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University


More information about the bind-users mailing list