Thread handling

[Hamid Maadani]

> BIND does have dyndb support, since 9.11.
> As far as I know, though, the only two dyndb modules in existence are
> the bind-dyndb-ldap modiule that was written by Red Hat as part of
> FreeIPA, and a toy module used for testing. If you were interested in
> writing your MongoDB module for dyndb instead of DLZ, I'd be quite
> excited about that, I've long hoped the API would get more use.

Interesting. I looked in the contrib directory and only found the DLZ modules there. Can you please point me in the direction of the source code for that toy module?
I would definitely work on a mongo-dyndb implementation as well, when the time permits.
> I am fairly confident that any advantage from shared cache will be lost because the extra latency caused by communication with the MongoDB (or any other no-sql systems).
> Perhaps, describing the use case first (why do you want to use MongoDB at all) might have the benefit of not wasting time on your end.
This is a bit confusing to me. As I understand it, a normal bind zone is loaded into memory, and requests are served from that memory-cache, hence super fast.
DLZ modules however, make a call to the backend database per query. Which would introduce latency (in my tests, 50ms when using an Atlas cluster in the same geographical region). However, why would this be specific to no-sql databases?! Doesn't this also apply to any sql based DB?

Now, an advantage of DLZ, is any change you make to the backend DB takes place immediately without the need to reload the server. Not a huge advantage in my personal opinion, but I do see the use case for it.
Looking for a way to load queried records from a backend database into memory to speed up the responses, I found posts about the DynDB API. If Evan can kindly point me in the right direction there, I will be developing both DLZ and DynDB modules for MongoDB, as I do see use cases for each one.

The caching question that I asked, was more around having a workaround without DynDB, because I was under the impression that DynDB API is not available at the moment. My understanding of a BIND caching server (and admittedly , I am by no means an advanced user when it comes to BIND), is that it would query records from another server, and cache them for the life (TTL) of that record, and serve it. This cache, exists in memory, correct?
So in theory, if I was to use a DLZ to keep my records in a backend DB, I can technically create a BIND server with the DLZ enabled (let's say a docker image), and then put a caching server in front of it, which is "customer facing".
That way, all queries will come to the caching server, and will be served super fast because they are cached in memory, but the actual records live in a backend DB somewhere.
Long story short, I was trying to see if the same can be achieved with one single instance instead of two, which sounds like it can not be done.

Regards
Hamid Maadani

August 24, 2022 12:40 AM, "Ondřej Surý" <ondrej at isc.org (mailto:ondrej at isc.org?to=%22Ond%C5%99ej%20Sur%C3%BD%22%20<ondrej at isc.org>)> wrote:
On 24. 8. 2022, at 8:48, Evan Hunt <each at isc.org (mailto:each at isc.org)> wrote: 

In the absence of that, is caching from DLZ a possible configuration
on a single BIND server?
Not DLZ, no. And I'm not sure dyndb can be used for the cache database,
either; do you know something about it that I don't?

It would definitely be easier to *make* dyndb work for the cache;
it has all the necessary API calls, and DLZ doesn't. But I don't
know a way to configure it to take the place of the cache currently.
If you do, please educate me. 
I am fairly confident that any advantage from shared cache will be lost because the extra latency caused by communication with the MongoDB (or any other no-sql systems).

Perhaps, describing the use case first (why do you want to use MongoDB at all) might have the benefit of not wasting time on your end.

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org (mailto:ondrej at isc.org)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220824/8101c121/attachment-0001.htm>