NOTIFY from masters when slave provides several views

Jonathan Petersson jpetersson at garnser.se
Fri Mar 27 00:11:09 UTC 2009


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+bindusers at 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
>        terry at tmk.com             New York, NY USA
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



More information about the bind-users mailing list