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
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: nsupdate and views
Mark, Thanks. I found where this was discussed here previously (Jan. 2003); apologies for not being thorough. - David Covey Deophysical Institute, University of Alaska Fairbanks To: David Covey david.co...@gi.alaska.edu Cc: bind-us...@isc.org From: Mark Andrews ma...@isc.org Subject: Re: nsupdate and views Date: Wed, 18 Mar 2015 14:01:28 +1100 Use different TSIG keys to direct the UPDATE request to the correct view. In message 5508dd86.kc1mmon8e03wtkto%david.co...@gi.alaska.edu, David Covey w rites: Hello all, I don't quite see how to dynamically manage multiple views of a zone. Specifically I have a zone name with both 'internal' and 'external' views that I'd like to manage with the nsupdate command. Is there a way to specify the zone+view using nsupdate? - David Covey Geophysical Institute, University of Alaska Fairbanks ___ 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 -- 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
nsupdate and views
Hello all, I don't quite see how to dynamically manage multiple views of a zone. Specifically I have a zone name with both 'internal' and 'external' views that I'd like to manage with the nsupdate command. Is there a way to specify the zone+view using nsupdate? - David Covey Geophysical Institute, University of Alaska Fairbanks ___ 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: nsupdate and views
Use different TSIG keys to direct the UPDATE request to the correct view. In message 5508dd86.kc1mmon8e03wtkto%david.co...@gi.alaska.edu, David Covey w rites: Hello all, I don't quite see how to dynamically manage multiple views of a zone. Specifically I have a zone name with both 'internal' and 'external' views that I'd like to manage with the nsupdate command. Is there a way to specify the zone+view using nsupdate? - David Covey Geophysical Institute, University of Alaska Fairbanks ___ 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 -- 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)
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 19:34, Tony Finch wrote: Constantin Stefanov cs...@parallel.ru 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: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 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
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
Re: Single slave zone definition for two view (cache file name problem)
Constantin Stefanov cs...@parallel.ru 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.finch d...@dotat.at http://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
