forwarder cache

[Hamid Maadani]

> Weird. Please send complete configs as attachments, along with a minimal test.com zone file required to start the server and we can have a look.

I think I have narrowed this down a bit. Let's see if the new info helps. I will upload the complete config otherwise.
For context, I have upgraded to alpine 3.17 (BIND 9.18.9)

My authoritative instance (NS2) was running on a DLZ module. In order to test Darren's config, I added a zone with local-file backend to it, and noticed the difference.
Here is the NS2 config for both of the zones now:
dlz XDB {
 database "dlopen /usr/lib/bind/dlz_xxx_mod.so xxx_params_xxx";
 search no;
};

zone "test.com" {
 type master;
 dlz XDB;
 allow-query { any; };
};

zone "test2.com" {
 type master;
 file "/etc/bind/ns2/db.test2.com";
 allow-query { any; };
};

I have not changed the forwarding config in NS1, but have removed all stale config so not to cause confusion.
My understanding is, this configurations defines two zones for which NS2 is authoritative (master or primary). for zone "test.com", response will be fetched from a backend DB, and for test2.com it will be read from a local file.

After restarting the server, I queried NS1 for "test2.com", and dumped the cache. I can see:
/ # cat /var/cache/ns1/named_dump.db 
;
; Start view _default
;
;
; Cache dump of view '_default' (cache _default)
;
; using a 0 second stale ttl
$DATE 20221130184023
; authanswer
test2.com. 3583 IN A 10.11.11.11
;
; Address database dump

So for the zone configured with a local-file, NS2 has responded correctly, and NS1 has cached it as an "authanswer". All good.
Now, I query NS1 for "test.com". I get a response of 10.10.10.10 which is correctly read from the backend database, indicating NS2 has looked it up and answered correctly. Dumping NS1 cache however:
; using a 0 second stale ttl
$DATE 20221130184239
; authanswer
test2.com. 3424 IN A 10.11.11.11
;
; Address database dump

I see no record for "test.com"!
This seems to me that any answers coming from a DLZ hosted zone on NS2, are not treated as an "authresponse" by NS1.
Is that something that needs to be implemented in the DLZ code? My understanding was that indicating "search no" for DLZ, and setting a specific zone with type "master" or "primary" would make NS2 authoritative for that zone, regardless of the backend.
Is that an incorrect assumption?

Regards
Hamid Maadani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221130/933102ff/attachment.htm>