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
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
