On 11/10/2010 3:17 PM, J. Thomsen wrote:
Is there a way or option to configure bind to do the following logic: If the
bind didn’t find a entry in a view 1 (internal view) it will search this
entry on the view 2 (external view) ?
Not to my knowledge. We had the same problem and ended up with using the hosts 
file for
the special IP addresses.
Hosts file? "Special IP addresses"? I don't quite understand your solution. The typical way to deal with these situations is to have two different views, internal and external, with the differentiated entries existing separately in their respective versions of the zone, and the entries which are common to both, shared via an $INCLUDE file.

Not sure why you felt it necessary to resort to hosts files. The $INCLUDE-file "trick" is incompatible with Dynamic Update, of course, but if you already -- as we do -- have Dynamic Update and some sort of programmatic front-end on it, why not add just add the logic in the front-end for the updates to go to whichever view(s) in which they need to be visible? What am I missing here?

It would have been nice to have been able to use BIND for everything.
This just illustrates that the simple view concept in BIND really needs an 
overhaul as I
have been advocating lately about groups of zones where the extended search is 
just done
on zones not on individual resource records.

"View"s in BIND was never meant to provide a general "search" function.

It's an alternative to running
-- multiple nameserver instances, listening on different interfaces, or
-- completely separate nameserver devices.

If you want fancy "extended search" capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND.

- Kevin


_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to