BIND View Option

Kevin Darcy kcd at
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.

         - Kevin

More information about the bind-users mailing list