forwarder cache

[Hamid Maadani]

Thank you for your response, Darren. Appreciate that.

> I do have my forwarders setup differently (ie: I have them only on a per domain level instead of at the options level)
> Not sure how that would make a difference for the problem you are having, however.

Just to double check, I changed my config to match that. Setup a specific forwarding zone in NS1 and turned off global forwarding. NS2 on, all good. NS2 off, No dice.
If I query test.com, I get the stale error in logs.
If I comment out the stale config options, reload and query test.com, I just get this in logs:
29-Nov-2022 21:57:49.931 queries: info: client @0x7f325e5a2108 192.168.56.1#57660 (test.com): query: test.com IN A +E(0) (172.17.0.3)
29-Nov-2022 21:57:49.931 resolver: debug 1: fetch: test.com/A
29-Nov-2022 21:57:49.933 query-errors: info: client @0x7f325e5a2108 192.168.56.1#57660 (test.com): query failed (SERVFAIL) for test.com/IN/A at query.c:7375

> The only difference is that my "authoritative" servers are not running at 127.0.0.1 but rather 192.168.40.142 and 40.182

Changed the IP to eth0 IP instead of loopback, no difference.

> Another difference is that these are all running in chroot jails with separate directories

In my setup, I have separated the instances by:
- using separate config directories (/etc/bind/ns1/ , /et/bind/ns2/)
- using separate work directories (/var/cache/ns1/ , /var/cache/ns2/)
- turning off PID file for NS2 (only one PID file exists, and it is for NS1)
- separating ports the listen on (NS1 -> 53, NS2 -> 153)
- separating control ports for rndc (953 for NS1 and 1953 for NS2)
instead of chrooting them.

For what I know, this should completely separate the instances apart, unless I'm missing something. Also, they are separate processes, so they do not share any memory unless there is something different in bind that I do not know about.

I still can not figure out why the cache does not work on NS1!

Regards
Hamid Maadani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221129/6e484688/attachment-0001.htm>