"in-view" behavior

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

"in-view" behavior

John Thurston

I need to define several views. They will be largely identical, probably
differing in only one zone definition. What I had hoped to do was define
all the common zones in an unused-view, and then use "in-view" to
reference the several zones in the other views.

view "initial" { {match-clients "none"; };
   zone foo { . . .};
   zone bar { . . .};
};

view "v1" { {match-clients key v1-key; };
   allow-transfer { key v1-key; };
   zone foo { in-view initial; };
   zone bar { in-view initial; };
   zone baz { . . .};
};

I had expected the zones foo and bar to be shared from a single instance
in memory, that BIND would use the match-client to get the traffic to
the appropriate view, and then use that view's allow-transfer list. But
the behavior I'm observing is the allow-transfer of view v1 isn't being
used.

When I use:
   rndc zonestatus bar IN v1
I can see the zone is defined on the primary. But when I try to transfer
it to the secondary using the v1-key, the request is REFUSED.

When I stuff the allow-transfer line from the "v1" view into the
"initial" view, the transfer initiated with v1-key succeeds.

I had been thinking of "allow-transfer" to be a property of a _view_,
but it now appears it may be assigned as a property to the _zones_
defined in that view.

So my specific questions are:
A) When I reference a zone with "in-view", can any properties be
    superseded?
B) If so, which properties?


(FWIW, BIND version 9.11.24 on the primary and 9.16.8 on the secondary.)


--
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
[hidden email]
Department of Administration
State of Alaska
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: "in-view" behavior

Mark Andrews


> On 31 Oct 2020, at 06:07, John Thurston <[hidden email]> wrote:
>
>
> I need to define several views. They will be largely identical, probably differing in only one zone definition. What I had hoped to do was define all the common zones in an unused-view, and then use "in-view" to reference the several zones in the other views.
>
> view "initial" { {match-clients "none"; };
>  zone foo { . . .};
>  zone bar { . . .};
> };
>
> view "v1" { {match-clients key v1-key; };
>  allow-transfer { key v1-key; };
>  zone foo { in-view initial; };
>  zone bar { in-view initial; };
>  zone baz { . . .};
> };
>
> I had expected the zones foo and bar to be shared from a single instance in memory, that BIND would use the match-client to get the traffic to the appropriate view, and then use that view's allow-transfer list. But the behavior I'm observing is the allow-transfer of view v1 isn't being used.
>
> When I use:
>  rndc zonestatus bar IN v1
> I can see the zone is defined on the primary. But when I try to transfer it to the secondary using the v1-key, the request is REFUSED.
>
> When I stuff the allow-transfer line from the "v1" view into the "initial" view, the transfer initiated with v1-key succeeds.
>
> I had been thinking of "allow-transfer" to be a property of a _view_, but it now appears it may be assigned as a property to the _zones_ defined in that view.
>
> So my specific questions are:
> A) When I reference a zone with "in-view", can any properties be
>   superseded?

No.

> B) If so, which properties?

None.

> (FWIW, BIND version 9.11.24 on the primary and 9.16.8 on the secondary.)
>
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> [hidden email]
> Department of Administration
> State of Alaska
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users