Hi Terry,
Each view has to be independently notified if an update takes place.
/Jonathan
On Thu, Mar 26, 2009 at 4:46 PM, <terry+bindus...@tmk.com> wrote:
> 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
>
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
