Re: Converting between zone file formats

2023-01-30 Thread Konstantin Stefanov

Hi,

I think you can achieve the same effect with dig, but it requires some 
preparations.


First, enable zone transfers for your slave zone from 127.0.0.1: add
allow-transfer {127.0.0.1;}; to your slave zone definition (or add 
127.0.0.1 there if you already have allow-transfer).


Then you can do dig from the same server:
dig @127.0.0.1 your.zone AXFR

Thus you'll get your slave zone in text format.

On 30.01.2023 10:33, Havard Eidnes via bind-users wrote:

Hi,

by default, the files written by BIND when acting as a slave is
not in "text" format, but is some binary file format, I beleive
what is referred to as "raw" format.

Once in a while it's desireable to be able to see the contents of
the slave zone file as plain text.  To that end I have previously
used named-compilezone to do this with

named-compilezone \
 -q -j -f raw -F text -o - \
 $z \
 $directory/$z

However... This does not appear to work anymore.

Earlier I ran BIND 9.16 on this host, but it has been upgraded to
9.18 (built and installed from local source).  It seems that a
while back (probably in the 9.16 era), named-compilezone was
changed to a symlink to named-checkzone, and it also looks like
BIND 9.18 no longer installs named-checkzone, so what I have as
named-checkzone appears to come from BIND 9.16.

Trying to use the procedure as above results in a named-checkzone
which hangs in select(), which is a bit strange when it's only
supposed to act on local files?!?

What should I now use instead of the above to convert the binary
zone file to back to the textual master zone file format?  Please
don't say "that's not possible"...

(This might be important to be able to do if an upstream suffers
a catastrophe of some sort, as a step along the path to convert
this name server to be a master for the zone in question.  Being
a master implies being able to modify the zone, and doing that
with a binary file is ... slightly inconvenient.)

Regards,

- Håvard


--
Константин Стефанов,

Лаборатория параллельных информационных технологий НИВЦ МГУ

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Question About Recursion In A Split Horizon Setup

2020-04-17 Thread Konstantin Stefanov

On 17.04.2020 17:56, Tim Daneliuk wrote:

On 4/17/20 9:50 AM, Bob Harold wrote:


Agree, that's odd, and not what the man page says.  Any chance that there is 
some other DNS helper running, like resolved, nscd, dnsmasq, etc?


Nope.  This is vanilla FreeBSD with vanilla bind running.
Lately vanilla FreeBSD has unbound as caching and recursive DNS server. 
Did you turn it off?





'dig' should tell you what address it used, at the bottom of the output - what 
does it say?




;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE  rcvd: 83


Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation?  (This is an IPV4 only environment).





--
Konstantin Stefanov
___
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: named.conf Default Location?

2016-01-13 Thread Konstantin Stefanov
On 12.01.2016 20:29, Tim Daneliuk wrote:
> I have two FreeBSD 10 machines on which I have installed the bind99 port.
> 
> The manpage for named on machine 1 says that it looks for the named.conf
> by default in /usr/local/etc/namedb.  Machine 2's manpage says it looks
> in /etc/namedb.   
> 
> Which is correct?  Is the /etc/namedb symlink even needed anymore?
Are they freshly installed FreeBSD 10 or were update to ver 10 from 9 or
earlier? In FreeBSD 9 there was in-base named which had config at
/et/namedb. Maybe the manpage on one of the machines is from earlier
versions? Try man -a named.conf and see if there are other vresions of
man page.

By default bind99 port uses /usr/local/etc/namedb, but it used to have
REPLACE_BASE option, which instructed it to use /etc/namedb, so you may
check it.

-- 
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: Identify source of rndc reconfig command?

2015-08-26 Thread Konstantin Stefanov
Hi, Robert.

As I understand, something is calling rndc on your localhost. So you may
try (untested by me):

Find rndc binary,

mv rndc rndc.ORIG

Replace rndc with script which will execute something like
ps fax  /tmp/rndc.log
then exec rndc.ORIG with the same arguments.

Then you will see who invoked your rndc.
Don't forget to use full path to rndc.ORIG, as you will never know which
current directory will be when your rndc replacement will be executed
and what the value of PATH will be.

On 25.08.2015 0:01, Robert Senger wrote:
 Hi all,
 
 after upgrading from Debian Wheezy to Jessie, bind9 receives rndc
 reconfig commands every 30 minutes. I've never seen this before. Some
 of my own scripts run rndc restart/reload after fiddling with network
 interfaces, but none of these is the source of the observed 30 minutes
 interval. There are also no cron jobs.
 
 In the bind9 logs I see this:
 
 24-Aug-2015 22:53:43.431 general: info: received control channel command 
 'reconfig'
 24-Aug-2015 22:53:43.458 general: info: loading configuration from 
 '/etc/bind/named.conf'
 ... [more than 350 lines reconfig log]
 
 Running tcpdump on the lo interface gives me this:
 
 root@prokyon:/etc/bind# tcpdump -i lo port 953
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 
 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
 0,nop,wscale 5], length 0
 21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 
 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 
 196635776 ecr 196635776,nop,wscale 5], length 0
 21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 
 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0
 21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, 
 ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
 21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 
 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
 21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, 
 ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 
 179
 21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 
 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
 ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 
 172
 21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 
 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
 ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 
 183
 21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
 21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 
 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
 21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
 21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 
 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
 
 Is there a way to identify the source of these reconfig commands? It's
 really annoying as it messes up the log with 350 useless lines every 30
 minutes.
 
 Thanks!
 
 Robert
  
 

-- 
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)

2015-03-19 Thread 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
___
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)

2015-03-18 Thread Konstantin Stefanov
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)

2015-03-18 Thread Konstantin Stefanov
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)

2015-03-18 Thread Konstantin Stefanov
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)

2015-03-18 Thread Konstantin Stefanov
On 18.03.2015 16:55, Steven Carr wrote:
 On 18 March 2015 at 13:30, Konstantin Stefanov cs...@parallel.ru 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)

2015-03-18 Thread Konstantin Stefanov


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)

2015-03-18 Thread Konstantin Stefanov
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)

2015-03-18 Thread Konstantin Stefanov
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