DLZ data caching -- Please tell me there is *SOME* caching for the db drivers

[Kal Feher]

I know this isn't exactly what you asked for, but why not put caching BIND
servers in front of the DLZ enabled servers?

I too run a few DLZ servers (9.3 where it was a patch) and I've also noted
the dearth of documentation.

Since the code is now part of BIND it is certainly appropriate that
documentation appear in the ARM which it doesn't AFAIK.


On 27/6/07 7:56 AM, "Weston Weems" <wweems at gmail.com> wrote:

> In searching for information on the subject, it would seem I'm not the only
> person with this request... but please hear me out...
> Current situation, we needed something administed via remote machines (not
> through unix, and logins, or putting files here and there, or berkley db)
> and for this, postgres+bind dlz has been fantastic. It works EXACTLY as I'd
> hoped it would, and with proper replication, I've got to say its easily the
> best experience I've had with bind.
> 
> The problem, regardless of what everyone says I am not ready and willing to
> just laydown without a fight about the subject of at least a small amount of
> caching to eliminate a hit per query to postgres database.
> 
> Arguments for and against ahve all been heard... and while I dont have a
> perfect solution for the problem I'd really like to know why there couldnt
> be *SOMETHING*, eg, extra col expected in the postgres DLZ queries for
> frequency of looking up against db or SOMETHING.
> 
> I've found VERY VERY little documentation on the subject, and was frankly
> hoping that some level of caching at the dlz level has been implemented and
> I am just missing it.
> 
> Thanks for any advice
> 
> Weston Weems
> 
> 
> 

-- 
Kal Feher