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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
