Re: Single slave zone definition for two view (cache file name problem)
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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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.
> >> 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. :)
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 18:37, Reindl Harald wrote: > > Am 18.03.2015 um 16:31 schrieb Konstantin Stefanov: >> I wrote earlier and may repeat again. The feature for me is not using >> the same file, the feature is having a clear and maitainable config. In >> this case it means to have only one description for a zone. > > did you ever consider provisioning your configs template based? > > shouldn't be too hard to implement with a small sql database and a nice > webinterface, we do that to automatically add no-mail SPF, null-MX, > honeypot-backup-mx and what not for years with great success It's a definite overkill for me. I was quite happy with manually editing text configs several times a year. Now I'll write a script and will be a little less happy, but SQLs, webinterfaces, honeypots... No and no, I do not need it at all. > > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
Am 18.03.2015 um 16:31 schrieb Konstantin Stefanov: I wrote earlier and may repeat again. The feature for me is not using the same file, the feature is having a clear and maitainable config. In this case it means to have only one description for a zone. did you ever consider provisioning your configs template based? shouldn't be too hard to implement with a small sql database and a nice webinterface, we do that to automatically add no-mail SPF, null-MX, honeypot-backup-mx and what not for years with great success signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 18:10, wbr...@e1b.org wrote: > From: Konstantin Stefanov > >> 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. > > "That's not a bug, it's a feature!" Yeah, old joke about software > quality. > > Software should prevent you from doing things that cause errors. The bug > was that you were allowed to used the same file in multiple views. The > bug was not the errors that could occur if you did this. The bug was > fixed and you can now longer use the same file. I don't care about using the same file, I do care about clear config. If there was a feature which allow to use different files with one description of zone, I would be happy. But there isn't. I wrote earlier and may repeat again. The feature for me is not using the same file, the feature is having a clear and maitainable config. In this case it means to have only one description for a zone. > Maybe one of the other available DNS server packages will allow this. > > > > > > Confidentiality Notice: > This electronic message and any attachments may contain confidential or > privileged information, and is intended only for the individual or entity > identified above as the addressee. If you are not the addressee (or the > employee or agent responsible to deliver it to the addressee), or if this > message has been addressed to you in error, you are hereby notified that > you may not copy, forward, disclose or use any part of this message or any > attachments. Please notify the sender immediately by return e-mail or > telephone and delete this message from your system. > -- Константин Стефанов, Лаборатория параллельных информационных технологий НИВЦ МГУ тел. +7 (495) 939-23-41 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 17:18, Matus UHLAR - fantomas wrote:
> rOn 18.03.15 17:10, Konstantin Stefanov wrote:
>> 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.
>
> those bugs _were_ fixed: the in-view statement and prevention from using
> the same file multiple times (I remember discussion about issues coming from
> those here on the list).
>
> you are complaining about your broken configuration worked.
> Sorry, I gave up arguing with you.
Indeed, my configuration worked although broken. And now I can't make
the configuration as simple. Yes, the new 'in-view' makes the config
possible, but allowing simple configuration is a valuable feature in my
view.
Look at masters lists. You may write any config without it, simply by
repeating the same IPs where needed. But is masters lists a feature?
Ceratinly it is, it makes configuration easier and more maintainable.
The same is with my broken config. I am now able to have correct config
by repeating slave zones descrition twice.
But the feature 'ability to have only one description of common slave
zones' is now lost. And 'in-view' is not a substitution, as it again
requires two different description for one zone.
I'm trying to convey that in my view the feature here is not what
'in-view' solves. For me the feature that is lost allowed me to have
neat config.
A substitute could be, for example, some variable with view name to use
in file directive. If I could write somesthing like
zone "aaa" {
type slave;
file "aaa.$viewname";
};
that would allow me to write simple config again. Other variants are
possible, for example allowing different 'directory' option setting for
different views, as it again making possible to point to different files
with the same line.
I see developers' point and understand why reference to a zone (in-view)
is easier to program and debug than finding when referencing two
writable files is correct and when it is not, and programming checks.
And disabling referencing two writable files seems to be clever way,
especially since there is new 'in-view' feature.
For me as an user 'in-view' make sense with three or more views (than I
would have two descriptions, one full and one with in-view) for any
number of view.
But in case of two views (my case) in-view feature gives almost nothing.
I still have to have two files, and waht difference: two with different
filenames or one with filename and one with in-view. The script for the
first case is even simpler.
So again, for me the feature that worked is lost without any equal
substitute.
If you think that feature is of no real worth - OK, I don't know if
having exactly two views with a load of identical zones is a frequent
case. But the only thing I want to say - that there was a feature that
is now lost. Maybe that feature existed only by an oversight, but I used
it for five years, and it worked (for me, again).
And thanks for spending your time.
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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
journal. There is no shared access to a journal.
> 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.
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.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
rOn 18.03.15 17:10, Konstantin Stefanov wrote: 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. those bugs _were_ fixed: the in-view statement and prevention from using the same file multiple times (I remember discussion about issues coming from those here on the list). you are complaining about your broken configuration worked. Sorry, I gave up arguing with you. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 16:55, Steven Carr wrote: > On 18 March 2015 at 13:30, Konstantin Stefanov 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18 March 2015 at 13:30, Konstantin Stefanov 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. > 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") Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 16:12, Lightner, Jeff wrote: > It isn't really that hard to maintain two separate zone files for > each domain. We've been doing it for years. It isn't. But maintaining one file is easier. And having to maintain two after five years everything worked fine with one is annoying. > It isn't really clear why you're using views if all your zone files > are the same as you seem to imply. Here we do views specifically because > for some domains the zone files DO need to be different between internal > and external views. While others are the same as I noted before it is > very easy to simply edit one file then copy it to the other. 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. > -Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Konstantin Stefanov > Sent: Wednesday, March 18, 2015 6:31 AM > To: bind-users@lists.isc.org > Subject: Re: Single slave zone definition for two view (cache file name > problem) > > On 18.03.2015 13:22, Matus UHLAR - fantomas wrote: >>>> On 18.03.15 12:05, Constantin Stefanov wrote: >>>>> I can't. It stopped working after upgrade to 9.10, but worked >>>>> before with 9.6. And the question is how to keep the config as >>>>> simple as it was before upgrade. >>>> >>>> I mean, the "in-view" definitions... >> >> On 18.03.15 13:10, Konstantin Stefanov wrote: >>> So now I have to have two definitions for every slave zone in >>> different files. Well, it is the thing I did, but I do not like it. >>> >>> Requirement to have 2 synced definitions in 2 different places leads >>> to bugs. >> >> and what did you have before? >> multiple definitions of the same zones with the same filenames, which >> leads to bugs (although you were lucky not to encounter them) > Yes, I was lucky and everything worked for me as I thought it had to be. > >> >> now you can have: >> >> definitions of zones with filename in one general view >> >> file with definitions of zones with "in-view". >> >> multiple inclusions of the file in multiple views. > And now I am unlucky as I have to make my cofig more complex, confusing and > bug-prone to achieve the same effect. > > But I'm lucky enough to have three options to choose how to spoil my config. > >> >>>>>> the only other way is stop using views... >> ... you still can stop using views. > And I can still stop using DNS. > > If I only could stop using views, I would not ask the question. > > -- > Konstantin Stefanov, > > Research Computing Center > M.V Lomonosov Moscow State University > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Single slave zone definition for two view (cache file name problem)
It isn't really that hard to maintain two separate zone files for each domain. We've been doing it for years. It isn't really clear why you're using views if all your zone files are the same as you seem to imply. Here we do views specifically because for some domains the zone files DO need to be different between internal and external views.While others are the same as I noted before it is very easy to simply edit one file then copy it to the other. -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Konstantin Stefanov Sent: Wednesday, March 18, 2015 6:31 AM To: bind-users@lists.isc.org Subject: Re: Single slave zone definition for two view (cache file name problem) On 18.03.2015 13:22, Matus UHLAR - fantomas wrote: >>> On 18.03.15 12:05, Constantin Stefanov wrote: >>>> I can't. It stopped working after upgrade to 9.10, but worked >>>> before with 9.6. And the question is how to keep the config as >>>> simple as it was before upgrade. >>> >>> I mean, the "in-view" definitions... > > On 18.03.15 13:10, Konstantin Stefanov wrote: >> So now I have to have two definitions for every slave zone in >> different files. Well, it is the thing I did, but I do not like it. >> >> Requirement to have 2 synced definitions in 2 different places leads >> to bugs. > > and what did you have before? > multiple definitions of the same zones with the same filenames, which > leads to bugs (although you were lucky not to encounter them) Yes, I was lucky and everything worked for me as I thought it had to be. > > now you can have: > > definitions of zones with filename in one general view > > file with definitions of zones with "in-view". > > multiple inclusions of the file in multiple views. And now I am unlucky as I have to make my cofig more complex, confusing and bug-prone to achieve the same effect. But I'm lucky enough to have three options to choose how to spoil my config. > >>>>> the only other way is stop using views... > ... you still can stop using views. And I can still stop using DNS. If I only could stop using views, I would not ask the question. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 13:22, Matus UHLAR - fantomas wrote: >>> On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. >>> >>> I mean, the "in-view" definitions... > > On 18.03.15 13:10, Konstantin Stefanov wrote: >> So now I have to have two definitions for every slave zone in different >> files. Well, it is the thing I did, but I do not like it. >> >> Requirement to have 2 synced definitions in 2 different places leads to >> bugs. > > and what did you have before? > multiple definitions of the same zones with the same filenames, which leads > to bugs (although you were lucky not to encounter them) Yes, I was lucky and everything worked for me as I thought it had to be. > > now you can have: > > definitions of zones with filename in one general view > > file with definitions of zones with "in-view". > > multiple inclusions of the file in multiple views. And now I am unlucky as I have to make my cofig more complex, confusing and bug-prone to achieve the same effect. But I'm lucky enough to have three options to choose how to spoil my config. > > the only other way is stop using views... > ... you still can stop using views. And I can still stop using DNS. If I only could stop using views, I would not ask the question. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 13:02, Matus UHLAR - fantomas wrote: On 18.03.15 11:48, Constantin Stefanov wrote: then both views will refernce ther same writable file, won't they? Or am I missing something about "in-view" directive? On 18.03.2015 11:56, Matus UHLAR - fantomas wrote: maybe you could put all those zone definitions into one file and include it in each view. On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. I mean, the "in-view" definitions... On 18.03.15 13:10, Konstantin Stefanov wrote: So now I have to have two definitions for every slave zone in different files. Well, it is the thing I did, but I do not like it. Requirement to have 2 synced definitions in 2 different places leads to bugs. and what did you have before? multiple definitions of the same zones with the same filenames, which leads to bugs (although you were lucky not to encounter them) now you can have: definitions of zones with filename in one general view file with definitions of zones with "in-view". multiple inclusions of the file in multiple views. the only other way is stop using views... ... you still can stop using views. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 99 percent of lawyers give the rest a bad name. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 13:02, Matus UHLAR - fantomas wrote: >>> On 18.03.15 11:48, Constantin Stefanov wrote: then both views will refernce ther same writable file, won't they? Or am I missing something about "in-view" directive? > >> On 18.03.2015 11:56, Matus UHLAR - fantomas wrote: >>> maybe you could put all those zone definitions into one file and include it >>> in each view. > > On 18.03.15 12:05, Constantin Stefanov wrote: >> I can't. It stopped working after upgrade to 9.10, but worked before >> with 9.6. And the question is how to keep the config as simple as it was >> before upgrade. > > I mean, the "in-view" definitions... So now I have to have two definitions for every slave zone in different files. Well, it is the thing I did, but I do not like it. Requirement to have 2 synced definitions in 2 different places leads to bugs. > >>> the only other way is stop using views... > -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.15 11:48, Constantin Stefanov wrote: then both views will refernce ther same writable file, won't they? Or am I missing something about "in-view" directive? On 18.03.2015 11:56, Matus UHLAR - fantomas wrote: maybe you could put all those zone definitions into one file and include it in each view. On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. I mean, the "in-view" definitions... the only other way is stop using views... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 11:56, Matus UHLAR - fantomas wrote:
> On 18.03.15 11:48, Constantin Stefanov wrote:
>> 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? Or am
>> I missing something about "in-view" directive?
>>
>> 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.
>
> maybe you could put all those zone definitions into one file and include it
> in each view.
I can't. It stopped working after upgrade to 9.10, but worked before
with 9.6. And the question is how to keep the config as simple as it was
before upgrade.
> the only other way is stop using views...
>
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 18.03.15 11:48, Constantin Stefanov wrote:
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? Or am
I missing something about "in-view" directive?
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.
maybe you could put all those zone definitions into one file and include it
in each view.
the only other way is stop using views...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
On the other hand, you have different fingers.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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? Or am
I missing something about "in-view" directive?
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.
On 18.03.2015 1:25, Mark Andrews wrote:
> Referencing the same writable file in multiple places in named can:
>
> * lead to corrupted journals
> * the wrong zone content being published in the wrong view
> * named not being able to serve zone content when restarted when the
> master is down
> * content not showing up in a timely manner
> * extra zone transfers recovering from the above
>
> If you failed to experience one or more of these you were lucky.
> There is a good chance that some of these things were happening and
> you were not even aware.
>
> We got bug reports about all of these events that were caused by
> the same writable file being referenced multiple times.
>
> Referencing the same writeable file multiple times has never been
> a supported configuration. This is now being caught.
>
> Mark
>
--
Константин Стефанов,
Лаборатория параллельных информационных технологий НИВЦ МГУ
тел. +7 (495) 939-23-41
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
Referencing the same writable file in multiple places in named can: * lead to corrupted journals * the wrong zone content being published in the wrong view * named not being able to serve zone content when restarted when the master is down * content not showing up in a timely manner * extra zone transfers recovering from the above If you failed to experience one or more of these you were lucky. There is a good chance that some of these things were happening and you were not even aware. We got bug reports about all of these events that were caused by the same writable file being referenced multiple times. Referencing the same writeable file multiple times has never been a supported configuration. This is now being caught. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 17.03.2015 19:34, Tony Finch wrote: > Constantin Stefanov wrote: >> >> 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. > > I have a similar situation on my workstation server, except in my case the > recursive view needs static-stub configurations for each zone in the > authoritative view. > > I have a script called named-listzones (attached) which reads named.conf > and outputs a list of zone name, view, and type. A bit of seddery in the > rc script re-generates the static-stub zone configuration whenever named > is started or reloaded. Tony, thanks for the script. I am doing something like that myself now, and using make as suggested in neighbour letter is a way, too. My grievance is that previously it worked without any scripting, and now the scripting is required. Maybe I do not see something? -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 17.03.2015 18:05, Lightner, Jeff wrote:
> 4.x would be quite ancient. Where are you getting those version
> numbers? You should be using 9.x these days so I suspect the BIND
> version isn't what you think it is.Is it possible the version
> you're reporting is you OS rather than your BIND?
>
> What is reported when you run "named -v"?
I mistyped, I meant 9.6, sorry.
> Anyway what we do is in our views is simply name the internal zone
> files the same as external and prepend internal- to the name.
>
> e.g. myzone.com = external zone file internal-myzone.com = internal
> zone file.
>
> If they're the same you can simply copy from one to the other.
> Sometimes they are not the same which is why you have views in the
> first place.
These files are created by named itself, so I can't simplycopy them. The
question is not where to get the files, the question is how to simplify
config. With 9.6 I could have only one definition for a zone shared
between 2 views, although it was considered incorrect.
After upgrade to 9.10 old config does not work and I see no way to keep
the config as simple.
The question is - how to make the config simple, as was available before
upgrade.
>
> -Original Message- From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Constantin
> Stefanov Sent: Tuesday, March 17, 2015 10:37 AM To:
> bind-users@lists.isc.org Subject: Single slave zone definition for
> two view (cache file name problem)
>
> Hello.
>
> After upgrading from BIND 4.6 to 4.10.2, named requires that
> different slave zone have separate file for cache.
>
> 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?
>
> 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?
>
> -- Konstantin Stefanov,
>
> Research Computing Center M.V Lomonosov Moscow State University
> ___ Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> bind-users mailing list bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___ Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> bind-users mailing list bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
Constantin Stefanov wrote:
>
> 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.
I have a similar situation on my workstation server, except in my case the
recursive view needs static-stub configurations for each zone in the
authoritative view.
I have a script called named-listzones (attached) which reads named.conf
and outputs a list of zone name, view, and type. A bit of seddery in the
rc script re-generates the static-stub zone configuration whenever named
is started or reloaded.
named-listzones | sed '
/ auth master$/bp
/ auth slave$/bp
d
:p
s// { type static-stub; server-addresses { ::1; }; };/
s/^/zone /
/"[.]"/d
' >named.static-stub
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Biscay, Fitzroy: East or northeast 5 or 6, occasionally 7 in south Fitzroy.
Moderate or rough. Showers. Moderate or good.#!/usr/bin/perl
use warnings;
use strict;
use re 'eval';
our $string_re = qr( " (?: [^"\\] | \\. )* " )x;
our $atom_re = qr( (?! zone \s+ | view \s+ )
[0-9A-Za-z!:._/-]+ )x;
our $stuff_re = qr( $string_re
| $atom_re
| (??{$block_re})
| \s+ | ;
)x;
our $block_re = qr( { (?: $stuff_re )+ } \s* ; )x;
our $type_re = qr( type \s+ ($atom_re) \s* ; )x;
my $conf = qx{named-checkconf -p @ARGV};
sub zone {
my ($zone,$view) = @_;
$conf =~ m(^ $type_re )x;
print "$zone $view $1\n";
$conf =~ s(^ $stuff_re )()x
until $conf =~ s(^ } \s* ; )()x;
}
my $head_re = qr(\s+ ($string_re) \s+ (?: ($atom_re) \s+ )? { \s*)x;
while ($conf =~ s(^ $stuff_re )()x) {
next unless $conf =~ s(^ (zone|view) $head_re )()x;
my $name = $2;
my $class = $4 || "IN";
if ($1 eq 'zone') {
zone $name, '_default', $class;
} else { # view
my $view = substr $name, 1, -1;
for (;;) {
last if $conf =~ s(^ } \s* ; )()x;
if ($conf =~ s(^ zone $head_re )()x) {
zone $1, $view, $2 || "IN";
}
last unless $conf =~ s(^ $stuff_re )()x;
}
}
}
die "parser failure\n" if $conf !~ m(^$);
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
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.
> 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?
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Single slave zone definition for two view (cache file name problem)
4.x would be quite ancient. Where are you getting those version numbers?
You should be using 9.x these days so I suspect the BIND version isn't what you
think it is.Is it possible the version you're reporting is you OS rather
than your BIND?
What is reported when you run "named -v"?
Anyway what we do is in our views is simply name the internal zone files the
same as external and prepend internal- to the name.
e.g. myzone.com = external zone file
internal-myzone.com = internal zone file.
If they're the same you can simply copy from one to the other. Sometimes they
are not the same which is why you have views in the first place.
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Constantin Stefanov
Sent: Tuesday, March 17, 2015 10:37 AM
To: bind-users@lists.isc.org
Subject: Single slave zone definition for two view (cache file name problem)
Hello.
After upgrading from BIND 4.6 to 4.10.2, named requires that different slave
zone have separate file for cache.
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?
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?
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
