On Thu, Jan 10, 2013 at 11:17 AM, Jan Gutter wrote:
> Thanks for the suggestions!
>
> I'm currently investigating two options: the local view and forwarded
> zones, and I'm going to check out if I can write a fast DLZ lookup to
> share the RPZ zones between the views. Caching is not a big problem
Thanks for the suggestions!
I'm currently investigating two options: the local view and forwarded
zones, and I'm going to check out if I can write a fast DLZ lookup to
share the RPZ zones between the views. Caching is not a big problem
here, the "shared zones" should only change about once per mon
IIRC provided you do NOT update the common zones dynamically, you can
share the files. This is a dirty solution, the risk is that on e view
may change a file and the other views using it will be out of sync.
On 10/01/13 0:34, Kevin Darcy wrote:
> On 1/9/2013 10:57 AM, Carl Byington wrote:
>>
On 1/9/2013 10:57 AM, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-01-09 at 14:37 +0200, Jan Gutter wrote:
So, here's my question: is there a way to share zones between views to
conserve memory?
One way is to put the master copy of those large zones in one vi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-01-09 at 14:37 +0200, Jan Gutter wrote:
> So, here's my question: is there a way to share zones between views to
> conserve memory?
One way is to put the master copy of those large zones in one view, then
define those zones in the other v
Hi
I've come across an interesting scalability issue with regards to how
our organization uses BIND. I'm putting up the question here, but I
have a sneaky suspicion that I'll have to solve this problem in the
source code. The way we use BIND seems to be slightly non-obvious, and
I'm really after a
6 matches
Mail list logo
