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
