Re: "in-view" behavior

2020-10-30 Thread Mark Andrews



> On 31 Oct 2020, at 06:07, John Thurston  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 Thurston907-465-8591
> john.thurs...@alaska.gov
> 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
> bind-users@lists.isc.org
> 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: ma...@isc.org

___
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


"in-view" behavior

2020-10-30 Thread 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 Thurston907-465-8591
john.thurs...@alaska.gov
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users