forwarder cache

[Ondřej Surý]

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.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 30. 11. 2022, at 20:00, Hamid Maadani <hamid at dexo.tech> wrote:
> 
> 
> 
> > 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
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221130/5d9dd75b/attachment-0001.htm>