> Matus UHLAR - fantomas wrote:
> > I would now like to have one main config that would include small files
> > containing those statements.
> >
> > Since listen-on and notify are in options statement; while
> > statistics-channel is a statement of its own, I would like to know, if
> > it's possible to define multiple options {} statements or do I have to
> > include two files.
On 01.03.10 15:25, Cathy Almond wrote:
> No - you can only have one options {}; statement
> > Another question is, can I use master {} as ACL or do I have to define
> > the same IP sets in masters {} and acl {}. Can they at least have the same
> > names?
>
> I can see what you're thinking if you have only a straightforward list
> of IP addresses in your ACL, but no, this won't work because
> fundamentally the usage/syntax is not the same for both. A masters list
> is a list of hosts (by IP address) that a slave server might contact to
> refresh a zone whereas an ACL is used for matching purposes (with a
> whole bunch of special syntax options).
I know this difference, I was thinking that masters{} contains ips-only
which, in theory, could be used in ACL (while acl can contain IP range,
which is apparently not imaginable in masters {} statement).
I understand this as the internal structures being so different that using
masters {} in acl {} can't work.
> I believe that you would be able to use the same name twice - once as an
> ACL and once as a masters_list, but it has the potential to cause
> confusion to anyone else reading or updating the configuration. But you
> should do what's best for your implementation.
That's what I am asking. each of my servers has a few peers I want to
configure them in masters {} and acl {} both. I found defining
peers_acl and peers_masters as a bit redundant while doing a small mistake
in either of them could result to unexpected behaviour (while doing the same
in both would apparently highlight the error).
We've been solving the same problem with other software by defining IPs of
internal/external interfaces and peers as peer1..peerN in /etc/hosts and
configuring hostnames instead of IPs there. BIND doesn't use hosts so I
would invite some kind of #define's (or, using /etc/hosts etc).
--
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
