NOTIFY from masters when slave provides several views
terry+b...@tmk.com
slave server? - RESOLVED" thread, but seems to be a different situation in
which the previous answer doesn't apply.
I have 3 nameservers, which we'll call ns1, ns2, and ns3. These servers
are primarily slave servers for stealth master servers (that last part
shouldn't really matter).
ns1, ns2, and ns3 operate with three views each - internal, customer, and
external. Internal is for the ISP's infrastructure systems, customer is for
customers (and allows recursion), and external is for the rest of the net
(no recursion, just authoritative answers for the zones it serves).
The master servers can be in address ranges covered by any of those views
as well - the ISP's own zones come from a server in the internal view, most
customer zones come from servers in the customer view, with a few coming
from servers in the external view.
Importantly, neither the masters nor ns1/2/3 have different zone data in
different views - the answers are always the same.
As an example, if ns1 gets a NOTIFY for a slave zone from a master in an
address covered by the customer view, it will do an xfer of the zone, but
only for ns1's customer view. The internal and external views won't trans-
fer until the expiry/refresh time for the zone fires.
Also important is that there are a *lot* of zones, and they all live in
an external include file (which, itself, is a collection of smaller include
files), which are all auto-generated from an external database. So it would
be very difficult to change that. Also, most of the masters are on customer
systems with a variety of nameserver versions, and asking them to add addit-
ional IP addresses (or indeed, make any changes at all) would also be very
difficult.
What I'd like is some way to tell BIND that if it gets a NOTIFY for a
zone, it should transfer that zone for all views, not just the matching
view.
The BIND versions in use are 9.6.0-P1 and 9.6.1b1.
Here's a censored example of the relevant parts of the named.conf file:
// The internal view allows everything
view "internal" in {
match-clients { internal; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
// Root hints
//
zone "." {
type hint;
file "named.root";
};
// snip... (internal-only zones removed from example)
// Customer zones
//
include "includes.conf";
};
// The customer view allows everything too, but has a different nane for
// statistics gathering purposes, and might have restrictions added later
view "customer" in {
match-clients { customer; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
// Root hints
//
zone "." {
type hint;
file "named.root";
};
// Customer zones
//
include "includes.conf";
};
// The external view allows queries of zones we serve, but not recursion
view "external" in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
// Root hints
//
zone "." {
type hint;
file "named.root";
};
// Customer zones
//
include "includes.conf";
};
Terry Kennedy http://www.tmk.com
te...@tmk.com New York, NY USA
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Jonathan Petersson
Each view has to be independently notified if an update takes place.
/Jonathan
On Thu, Mar 26, 2009 at 4:46 PM, <terry+b...@tmk.com> wrote:
> =A0This question is related to the prior "Internal and External view on s=
ame
> slave server? - RESOLVED" thread, but seems to be a different situation in
> which the previous answer doesn't apply.
>
> =A0I have 3 nameservers, which we'll call ns1, ns2, and ns3. These servers
> are primarily slave servers for stealth master servers (that last part
> shouldn't really matter).
>
> =A0ns1, ns2, and ns3 operate with three views each - internal, customer, =
and
> external. Internal is for the ISP's infrastructure systems, customer is f=
or
> customers (and allows recursion), and external is for the rest of the net
> (no recursion, just authoritative answers for the zones it serves).
>
> =A0The master servers can be in address ranges covered by any of those vi=
ews
> as well - the ISP's own zones come from a server in the internal view, mo=
st
> customer zones come from servers in the customer view, with a few coming
> from servers in the external view.
>
> =A0Importantly, neither the masters nor ns1/2/3 have different zone data =
in
> different views - the answers are always the same.
>
> =A0As an example, if ns1 gets a NOTIFY for a slave zone from a master in =
an
> address covered by the customer view, it will do an xfer of the zone, but
> only for ns1's customer view. The internal and external views won't trans-
> fer until the expiry/refresh time for the zone fires.
>
> =A0Also important is that there are a *lot* of zones, and they all live in
> an external include file (which, itself, is a collection of smaller inclu=
de
> files), which are all auto-generated from an external database. So it wou=
ld
> be very difficult to change that. Also, most of the masters are on custom=
er
> systems with a variety of nameserver versions, and asking them to add add=
it-
> ional IP addresses (or indeed, make any changes at all) would also be very
> difficult.
>
> =A0What I'd like is some way to tell BIND that if it gets a NOTIFY for a
> zone, it should transfer that zone for all views, not just the matching
> view.
>
> =A0The BIND versions in use are 9.6.0-P1 and 9.6.1b1.
>
> Here's a censored example of the relevant parts of the named.conf file:
>
> // The internal view allows everything
>
> view "internal" in {
>
> =A0 =A0 =A0 =A0match-clients { internal; };
> =A0 =A0 =A0 =A0recursion yes;
> =A0 =A0 =A0 =A0additional-from-auth yes;
> =A0 =A0 =A0 =A0additional-from-cache yes;
>
> =A0 =A0 =A0 =A0// Root hints
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0zone "." {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type hint;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0file "named.root";
> =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0// snip... (internal-only zones removed from example)
>
> =A0 =A0 =A0 =A0// Customer zones
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0include "includes.conf";
>
> };
>
> // The customer view allows everything too, but has a different nane for
> // statistics gathering purposes, and might have restrictions added later
>
> view "customer" in {
>
> =A0 =A0 =A0 =A0match-clients { customer; };
> =A0 =A0 =A0 =A0recursion yes;
> =A0 =A0 =A0 =A0additional-from-auth yes;
> =A0 =A0 =A0 =A0additional-from-cache yes;
>
> =A0 =A0 =A0 =A0// Root hints
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0zone "." {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type hint;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0file "named.root";
> =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0// Customer zones
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0include "includes.conf";
>
> };
>
> // The external view allows queries of zones we serve, but not recursion
>
> view "external" in {
>
> =A0 =A0 =A0 =A0match-clients { any; };
> =A0 =A0 =A0 =A0recursion no;
> =A0 =A0 =A0 =A0additional-from-auth no;
> =A0 =A0 =A0 =A0additional-from-cache no;
>
> =A0 =A0 =A0 =A0// Root hints
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0zone "." {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type hint;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0file "named.root";
> =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0// Customer zones
> =A0 =A0 =A0 =A0//
> =A0 =A0 =A0 =A0include "includes.conf";
>
> };
>
> =A0 =A0 =A0 =A0Terry Kennedy =A0 =A0 =A0 =A0 =A0 =A0 http://www.tmk.com
> =A0 =A0 =A0 =A0t...@tmk.com =A0 =A0 =A0 =A0 =A0 =A0 New York, NY USA
Niall O'Reilly
> Importantly, neither the masters nor ns1/2/3 have different zone data in
> different views - the answers are always the same.
If you don't have different zone data per view, I don't
understand what purpose the views serve, that could not
be met using other configuration options. From what you
describe, they seem to be getting in the way.
/Niall
Terry Kennedy
> On Thu, 2009-03-26 at 19:46 -0400, terry+b...@tmk.com wrote:
> > Importantly, neither the masters nor ns1/2/3 have different zone data in
> > different views - the answers are always the same.
>
> If you don't have different zone data per view, I don't
> understand what purpose the views serve, that could not
> be met using other configuration options. From what you
> describe, they seem to be getting in the way.
Let me clarify - for a zone in more than one of the views, that zone's
data doesn't vary by zone. The "internal" view has some zones not found
in the "customer" or "external" views.
Also, the external view doesn't provide recursion, while the customer
and internal ones do.
If you can describe how to handle the recursion issue without using
views or multiple DNS servers, I'd be very interested.
Terry Kennedy http://www.tmk.com
te...@tmk.com New York, NY USA
Niall O'Reilly
> If you can describe how to handle the recursion issue without using
> views or multiple DNS servers, I'd be very interested.
Perhaps
allow-recursion { address_match_list };
would meet your needs. See section 6 of the ARM.
/Niall
Barry Margolin
Terry Kennedy <terry+b...@tmk.com> wrote:
> Niall....@ucd.ie wrote:
> > On Thu, 2009-03-26 at 19:46 -0400, terry+b...@tmk.com wrote:
> > > Importantly, neither the masters nor ns1/2/3 have different zone data in
> > > different views - the answers are always the same.
> >
> > If you don't have different zone data per view, I don't
> > understand what purpose the views serve, that could not
> > be met using other configuration options. From what you
> > describe, they seem to be getting in the way.
>
> Let me clarify - for a zone in more than one of the views, that zone's
> data doesn't vary by zone. The "internal" view has some zones not found
> in the "customer" or "external" views.
This sounds like a job for the allow-query option in the zone statements.
>
> Also, the external view doesn't provide recursion, while the customer
> and internal ones do.
And this is a job for allow-query and allow-query-cache.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
terry+b...@tmk.com
> > data doesn't vary by zone. The "internal" view has some zones not found
> > in the "customer" or "external" views.
>
I should have mentioned that I tried that, but got:
"option 'allow-query' is not allowed in 'forward' zone 'xxx.yyy.com'"
In fact, that's what forced me into views in the first place.
> >
> > Also, the external view doesn't provide recursion, while the customer
> > and internal ones do.
>
> And this is a job for allow-query and allow-query-cache.
What's the deal with "allow-query"? I did some lookups from a host on an
outside net (not in either the internal or customer views) and the server
answered queries for the zones it hosted regardless of whether it was set
to "allow-query { internal; customer; };" or "allow-query { any; };".
Barry Margolin
> > > Let me clarify - for a zone in more than one of the views, that zone's
> > > data doesn't vary by zone. The "internal" view has some zones not found
> > > in the "customer" or "external" views.
> >
> > This sounds like a job for the allow-query option in the zone statements.
>
> I should have mentioned that I tried that, but got:
> "option 'allow-query' is not allowed in 'forward' zone 'xxx.yyy.com'"
>
> In fact, that's what forced me into views in the first place.
Since forwarding is part of recursion, this will be handled by the
allow-recursion global option.
>
> > >
> > > Also, the external view doesn't provide recursion, while the customer
> > > and internal ones do.
> >
> > And this is a job for allow-query and allow-query-cache.
Sorry, I meant "allow-recursion" there.
> What's the deal with "allow-query"? I did some lookups from a host on an
> outside net (not in either the internal or customer views) and the server
> answered queries for the zones it hosted regardless of whether it was set
> to "allow-query { internal; customer; };" or "allow-query { any; };".
Do you still have views configured? I think the view options override
the global options.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***