forwarder cache

Hamid Maadani hamid at dexo.tech
Wed Nov 30 21:17:39 UTC 2022


> 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, I have not been "withholding" or "censoring" information. Instead of dumping all data on you guys, I have tried to provide targeted information in order to help. If you prefer otherwise, I am ok with that, but I do not appreciate that attitude. If you and your team find this a "waste of time", feel free to ignore this thread and do not respond.
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, in my opinion.
Trying to attach them to this email, in the zip or tar.gz format seems not to work. My emails during past hour have not shown up on the mailing list.
I'll just append them at the end of this email.

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?
* NS1 config:
/etc/bind/ns1/named.conf:
include "/etc/bind/ns1/named.conf.options";
include "/etc/bind/ns1/named.conf.log";

/etc/bind/ns1/named.conf.log:
logging {
 channel bind_ns1_log {
 file "/var/log/named/bind_ns1.log" versions 3 size 5m;
 severity dynamic;
 print-category yes;
 print-severity yes;
 print-time yes;
 };
 category default { bind_ns1_log; };
 category update { bind_ns1_log; };
 category update-security { bind_ns1_log; };
 category security { bind_ns1_log; };
 category queries { bind_ns1_log; };
 category lame-servers { null; };
};

/etc/bind/ns1/named.conf.options:
options {
 listen-on port 53 { any; };
 listen-on-v6 { none; };

 directory "/var/cache/ns1";
 version "secured";

 recursion yes;
 allow-transfer { none; };
 allow-query { any; };

 forwarders {
 127.0.0.1 port 153;
 };
 forward only;

 dnssec-validation yes;

 statistics-file "/var/run/named.ns1.stats";

 auth-nxdomain no;
};
* NS2 config:
/etc/bind/ns2/named.conf:
include "/etc/bind/ns2/named.conf.options";
include "/etc/bind/ns2/named.conf.log";
include "/etc/bind/ns2/named.conf.include";

/etc/bind/ns2/named.conf.log:
logging {
 channel bind_ns2_log {
 file "/var/log/named/bind_ns2.log" versions 3 size 5m;
 severity dynamic;
 print-category yes;
 print-severity yes;
 print-time yes;
 };
 category default { bind_ns2_log; };
 category update { bind_ns2_log; };
 category update-security { bind_ns2_log; };
 category security { bind_ns2_log; };
 category queries { bind_ns2_log; };
 category lame-servers { null; };
};

/etc/bind/ns2/named.conf.options:
acl local_only {
 localhost;
};

options {
 listen-on port 153 { 127.0.0.1; };
 listen-on-v6 { none; };

 directory "/var/cache/ns2";
 pid-file none;
 version "secured";

 recursion no;
 allow-transfer { none; };
 allow-query { local_only; };

 dnssec-validation auto;

 statistics-file "/var/run/named.ns2.stats";

 auth-nxdomain no;
};

controls {
 inet 127.0.0.1 port 1953 allow { 127.0.0.1; };
};

/etc/bind/ns2/named.conf.include:
dlz XDB {
 database "dlopen /usr/lib/bind/dlz_mongodb_mod.so <MongoDB URI> 0";
 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; };
};

/etc/bind/ns2/db.test2.com:
$TTL 3600
@ IN SOA ns1.test2.com. admin.test2.com. (
 2022111501 ; Serial
 7200 ; Refresh
 1800 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache TTL
 IN NS ns1.test2.com.
 IN A 10.11.11.11

ns1 IN A 10.11.11.11
Regards
Hamid Maadani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221130/318d2b0e/attachment.htm>


More information about the bind-users mailing list