On 11/11/2010 1:22 PM, J. Thomsen wrote:
From a nameserver implementation and maintenance perspective, it's even
simpler for the data to already be present in the first view that
matches. Why complicate things more than that?
Because there is a need for it especially in large installations with
> From a nameserver implementation and maintenance perspective, it's even
>simpler for the data to already be present in the first view that
>matches. Why complicate things more than that?
Because there is a need for it especially in large installations with a large
number of
zones.
>Differen
On 11/11/2010 7:55 AM, J. Thomsen wrote:
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 special
>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
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 sh
In article ,
Stéphanas Schaden wrote:
> Hi all,
>
>
>
> we are in a situation here in our company that is: we need to send a
> internal IP address in a answer of a query when the source is a specific IP.
> So we created a new view and put the source address of this IP and
> configured the in
>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.
> What am I missing here?
The idea of avoiding front ends !
>"View"s in BIND was never meant to
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 usin
From: St?phanas Schaden 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) ?
Place the common piece in a separate include file:
view "view1" {
...
>
>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
10 matches
Mail list logo
