On 04/11/2014 10:59 AM, John Wobus wrote:
My understanding has been that two views that are masters for
a zone can safely share a zone file if the zone isn't dynamic (e.g.
dnsupdate, dnssec auto signing, etc), but that two views of
a slave zone shouldn't do that: you could have two
different vie
On 11 Apr 2014, at 18:59, John Wobus wrote:
> On Apr 9, 2014, at 4:14 AM, Steven Carr wrote:
>> However, assuming you are using views on the same IP address and not
>> splitting it across internal/external servers as that would screw up
>> NS records), you can reuse the same zone file so those z
On Apr 9, 2014, at 4:14 AM, Steven Carr wrote:
However, assuming you are using views on the same IP address and not
splitting it across internal/external servers as that would screw up
NS records), you can reuse the same zone file so those zones that
appear in both internal and external views ref
I had something similar a while back.
view 1
{
include external tables
include common tables
}
view 2
{
include internal tables
include common tables
}
Read that as tables for ONLY-internal or ONLY-external view.
I define each entry exactly once, also pushing stuff off to
the common include me
When you say "alternate zone", do you mean *schizophrenic* (i.e. some
leaf-node names resolve to different RDATA between the versions), or do
you mean only that the versions bear a subset/superset relation to each
other, at least with respect to leaf nodes (SOA/NS records being a
different matt
I faced a similar situation when setting up my servers. The way I handled
it (correctly or not) was to built the zones in the internal view as
master, and then the external view slaved to the internal master. That way
you can simply update your internals, and the external side automatically
popul
On 9 April 2014 13:09, Mike Meredith wrote:
> What I did in testing (and not very much at that) was to define the
> zones twice with different file names. Seemed to work fine ... at least
> the zone files and the journal files were created for both file names.
BIND will allow you to configure it
On Wed, 09 Apr 2014 12:05:07 +0300, Sotiris Tsimbonis
may have written:
> On 09/04/2014 11:14 πμ, Steven Carr wrote:
> > That's not how views work. When you match a view then that's it, you
> > don't continue to check other views.
Thanks. As I suspected views select _clients_. It might be a handy
On 9 April 2014 10:05, Sotiris Tsimbonis wrote:
> But when the zone is dynamic, this file "sharing" cannot be done between
> views.
>
> Updates only match one zone, and are kept in memory (or .jnl).
> So how would we make this work in dynamic zones?
> Maybe we should have one view axfr from the ot
On 09/04/2014 11:14 πμ, Steven Carr wrote:
> On 9 April 2014 08:37, Mike Meredith wrote:
>> Am I missing something obvious? Such as it should work, but I've
>> somehow messed up? Or perhaps there's some option I've missed? Or am I
>> out of luck?
>
> That's not how views work. When you match a vi
On 9 April 2014 08:37, Mike Meredith wrote:
> Am I missing something obvious? Such as it should work, but I've
> somehow messed up? Or perhaps there's some option I've missed? Or am I
> out of luck?
That's not how views work. When you match a view then that's it, you
don't continue to check other
11 matches
Mail list logo
