This question is related to the prior "Internal and External view on same
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-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
