forwarder cache

[Hamid Maadani]

> If you want the help from other people in this mailing list, withholding and
> censoring information isn’t the way forward. Please stop wasting everyone’s
> time by providing incomplete information. The fact that you are running DLZ on
> the NS2 is important, the other important information is how exactly does look
> the communication between ns1 and ns2. Don’t guess what might be useful for
> other people, provide full uncensored information. If you can’t do that,
> replicate the setup in the lab and provide full information about the setup and
> the communication between the servers and the client in the lab.

I have not been "withholding" or "censoring" information.
I am testing the new MongoDB DLZ I am developing in my lab setup, and providing the full config would not have helped at all in the first place.
Attaching it now, obviously omitting secure DB connection information from it, but I fail to see how it would help. Please see attached "config.tar.gz" file.

Again, my understanding is and has been, that configuring any DLZ with "search no", and configuring a zone of type "master"
using that DLZ as the backend, creates an authoritative DNS server for that zone. If that is the case, there should be
no difference between using a DLZ backend or a file backend in NS2 which is the authoritative server. That is all transparent to NS1.
As I have stated from the beginning, NS1 reaches out to NS2 on 127.0.0.1:153 using UDP.
Why would NS2 NOT respond with an authoritative answer in this case? Let me ask my question again: Is that something that needs to be implemented in the DLZ code? (currently using dns_sdlz_putrr_t to return what is found in DB). Wouldn't NS2 response be an "authanswer" by default since it has type master for the zone?

Regards
Hamid Maadani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221130/10e8c189/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf.tar.gz
Type: application/x-gzip
Size: 1166 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221130/10e8c189/attachment.bin>