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

/dev/rob0 rob0 at
Wed Mar 18 17:10:50 UTC 2015

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 "" {
> >> 		masters {IP;};
> >> 		file "slave/";
> >> 	};
> >> };
> >>
> >> view "view2" {
> >> 	zone "" {
> >> 		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.

> >> 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. :)
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

More information about the bind-users mailing list