BIND View Option

[Kevin Darcy]

On 11/10/2010 7:23 PM, J. Thomsen wrote:
>> Not sure why you felt it necessary to resort to hosts files.
> Well, I don't know how to configure ressource records in an include file and don't want to
> waste gigabytes of RAM duplicating zones.

If your main concern is resource consumption, maybe you should focus on 
developing some clever algorithm by which named could keep track of 
multiple references to the same data, without actually having to make 
separate copies of the data. Kind of a specialized "compression" 
algorithm. But, all of that could be done behind the scenes without 
introducing a new layer of configuration complexity.

>> What am I missing here?
> The idea of avoiding front ends !
What's a "front end" and what isn't, is largely in the eye of the 
beholder. I see "view"s as a "front end" to multiple, disparate data 
sets within BIND. You want to put more smarts into that "front end", 
whereas I think it's better to put the smarts into the stage of the 
pipeline just before BIND. Why is your approach inherently better than mine?
>> "View"s in BIND was never meant to provide a general "search" function.
> Alas they should never be changed.
>
>> If you want fancy "extended search" capabilities, look elsewhere or,
>> perhaps, figure out a way to implement this as a database backend to BIND.
> Right, I understand the point. Let us stay in the good old days.
> No bright ideas here. They may disturb the peace.
>
> What I am missing on this list is people, which do not see their primary task as keeping
> everything as it is and taking an interest in discussing new ideas.
>
To be honest, I don't really see anything new here. Similar ideas have 
been raised many times before.

                                                                         
                                                                 - Kevin