Puzzling scenario involving views - <resolution>
Peter Rabbitson
rabbit at rabbit.us
Tue Aug 17 16:31:18 UTC 2004
Here is the most efficient setup I could come up with. As I initially was
trying to achieve the two bind processes setup using views, the solution is
simply to let one view forward to another (using the external and internal
interfaces as a dividing point). So here is what we have:
acl "insiders" {
192.168.0.0/24;
127.0.0.1;
};
acl "secondary" {
xxx.xxx.xxx.xxx;
};
view "internal" {
match-clients { insiders; };
forward first;
forwarders { externalip; };
zone "example.com" {
type master;
file "example-internal.com";
notify no;
};
};
view "external" {
match-clients { any; };
zone "secondary.com" {
type slave;
file "slave.secondary.com";
masters { xxx.xxx.xxx.xxx; };
};
};
So when a query comes from insiders members for example.com - they get an AA
answer vie the internal view. When they ask about secondary.com - the external
ip will be queried which will cause it to be qualified for the external view.
This way the hint zone of the internal view will never be used (although we
do not define it it is still default compilled), but the hint zone of the
external view will be used which is on the same bind engine anyway. Maybe
match-destinations should be used as well for better readability.
Thank you Kevin for helping me to see bind views the way they should be seen :)
Peter
More information about the bind-users
mailing list