Possible to condition a view based on the interface the query comes in on?

[Evan Hunt]

On Thu, Nov 18, 2021 at 04:06:01PM -0800, Fred Morris wrote:
> Thanks for the encouragement folks, I forged ahead and I've got a
> different error now:
> 
>     "response-policy zone 'rpz1.m3047.net' for view standard is not a
>     master or slave zone"
> 
> That's the final denoument. There are several intermediate steps, such
> as moving all zone definitions into the views and converting all zone
> references in the second view to "in-view standard;" (where "standard"
> is the name of the first view).
> 
>   * There are a total of three RPZs.
>   * Two are utilized in the first view. (actually this is a lie)
>   * All three are utilized in the second view.
> 
> and the "lie" is that the "unused" RPZ is dynamically updated in the
> first view (that's where update requests are sent); I suppose I could
> jigger that so that the updates happen in the second view. But the
> stopper is that error message, and that RPZ is common to both views.
> 
> This is 9.12 FWIW.

(That's pretty outdated, BTW. End of life was 2.5 years ago.)

You can set things up so that one view will transfer a copy of a zone
from another, by using a TSIG key so that transfer requests from localhost
to localhost will be routed to the correct view:

    key them-key { ... };
    acl our-clients { ... };

    view us {
        match-clients { !key them-key; our-clients; };

        zone example.com {
            type secondary;
            file "example-secondary.db";
            primaries { 127.0.0.1 key them-key; };
        };
    };

    view them {
        match-clients { any; };

        zone example.com {
            type primary;
            file "example-primary.db";
            allow-transfer { localhost; };
        };
    };

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.