BIND View Option
kcd at chrysler.com
Wed Nov 10 23:34:57 UTC 2010
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.
More information about the bind-users