Puzzling scenario involving views - <resolution>

[Peter Rabbitson]

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