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

[Konstantin Stefanov]

On 18.03.2015 20:10, /dev/rob0 wrote:
> On Wed, Mar 18, 2015 at 06:11:56PM +0300, Konstantin Stefanov wrote:
>> 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.
> 
> view2 directs it to view1.  It's handled as if it came in view1.
> 
>>> journal.  There is no shared access to a journal.
> 
>> So in fact they both read from the same writable file.
> 
> Read-only access is not a problem, but in fact only view1 reads the 
> files; view2 asks view1, analogous to a query.  View1 already has the 
> entire zone in memory.  Zone data changes are written to memory and 
> to the journal at the same time.  Only view1 has to worry about the 
> journal, and that only for writing.
So there maybe other option to support sibgle-difinition.
One is allow defining zone out of views. Now it creates implicit
catch-all view and denies other views. But if this out-of-view zone
definitions will be considered as included in all views, something like
including all zones from outer scope with in-view directive, that will
solve the problem.

Another, more general option is to allow including one view into
another. Which views are allowed to be included is a quiestion. It may
be special views which match now clients, or something like that. And
including that view means that all zones from it are included into
another view as if they were again written with in-view directive.

I think one of these options is more easy to develop as basic thing
(in-view) is already there. But of course it's up to developers to
decided if ant of these is worth of efforts.


And thank you for you support.


>>>> 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'
> 
> Fair enough.  I would have tested, but didn't have time.
> 
>>> 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).
> 
> Yes, I saw that.  But I think that would be a more radical change, 
> thus less likely to make it into the BIND 9.10 tree.
> 
>> But I do not have needed skills to implement it myself.
> 
> Mark does, and if he thinks either is a good idea, he might. :)
> 

-- 
Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University