On 15. 11. 22 19:16, Chad Philip Johnson via bind-users wrote:
Here are the details of my config--it should be a mostly-vanilla
configuration. The design is such that there are two name servers on
each subnet and only the name servers of one subnet may issue queries to
nameservers on the other subnet.
As mentioned previously, all name lookups resolve without issue when
'forward only' is set, but the root servers are ALWAYS used whenever
'forward first' is enabled instead. This behavior is consistent across
all four systems.
Interesting. Is the query to root servers sent over IPv4 or IPv6?
Does the log say anything when it happens? If yes please send relevant
log lines.
If the answer to both questions is "no" then please send over PCAPs so
we can see the query going in and also the query going out.
Petr Špaček
__CONFIGURATION FOR NS1 ON subdomainA (192.168.0.50)__
options {
listen-on port 53 {
192.168.0.50;
127.0.0.1;
};
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query {
192.168.0.0/24; # subdomainA.domain.com subnet
192.168.1.50/32; # ns1.subdomainB.domain.com
192.168.1.51/32; # ns2.subdomainB.domain.com
127.0.0.1/32; # localhost
};
forward first;
forwarders {
1.1.1.1; # isp-provided name server 1
1.1.1.2; # isp-provided name server 2
};
recursion yes;
dnssec-validation no;
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
include "/etc/crypto-policies/back-ends/bind.config";
};
zone "." IN {
type hint;
file "named.ca";
};
zone "subdomainA.domain.com" {
type master;
file "/etc/named/zones-forward/db.subdomainA.domain.com.zone";
allow-transfer {
192.168.0.51; # ns2.subdomainA.domain.com
};
notify yes;
};
zone "subdomainB.domain.com" {
type forward;
forward only;
forwarders {
192.168.1.50; # ns1.subdomainB.domain.com
192.168.1.51; # ns2.subdomainB.domain.com
};
};
zone "domain.com" {
type master;
file "/etc/named/zones-forward/db.domain.com.zone";
allow-transfer {
192.168.0.51; # ns2.subdomainA.domain.com
};
notify yes;
};
zone "cosmeticdomain1.com" {
type master;
file "/etc/named/zones-forward/db.cosmeticdomain1.com.zone";
allow-transfer {
192.168.0.51;# ns2.subdomainA.domain.com
};
notify yes;
};
zone "cosmeticdomain2.com" {
type master;
file "/etc/named/zones-forward/db.cosmeticdomain2.com.zone";
allow-transfer {
192.168.0.51;# ns2.subdomainA.domain.com
};
notify yes;
};
zone "cosmeticdomain3.com" {
type master;
file "/etc/named/zones-forward/db.cosmeticdomain3.com.zone";
allow-transfer {
192.168.0.51;# ns2.subdomainA.domain.com
};
notify yes;
};
__CONFIGURATION FOR NS1 ON subdomainB (192.168.1.50)__
options {
listen-on port 53 {
192.168.1.50;
127.0.0.1;
};
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query {
192.168.1.0/24; # subdomainB.domain.com subnet
192.168.0.50/32; # ns1.subdomainA.domain.com
192.168.0.51/32; # ns2.subdomainA.domain.com
127.0.0.1/32; # localhost
};
forward first;
//forward only;
forwarders {
1.1.1.1; # isp-provided name server 1
1.1.1.2; # isp-provided name server 2
};
recursion yes;
dnssec-validation no;
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
include "/etc/crypto-policies/back-ends/bind.config";
};
zone "." IN {
type hint;
file "named.ca";
};
zone "subdomainB.domain.com" {
type master;
file "/etc/named/zones-forward/db.subdomainB.domain.com.zone";
allow-transfer {
192.168.1.51; # ns2.subdomainB.domain.com
};
notify yes;
};
zone "subdomainA.domain.com" {
type forward;
forward only;
forwarders {
192.168.0.50; # ns1.subdomainA.domain.com
192.168.0.51;# ns2.subdomainA.domain.com
};
};
zone "domain.com" {
type forward;
forward only;
forwarders {
192.168.0.50; # ns1.subdomainA.domain.com
192.168.0.51;# ns2.subdomainA.domain.com
};
};
zone "cosmeticdomain1.com" {
type forward;
forward only;
forwarders {
192.168.0.50; # ns1.subdomainA.domain.com
192.168.0.51;# ns2.subdomainA.domain.com
};
};
zone "cosmeticdomain2.com" {
type forward;
forward only;
forwarders {
192.168.0.50; # ns1.subdomainA.domain.com
192.168.0.51;# ns2.subdomainA.domain.com
};
};
zone "cosmeticdomain3.com" {
type forward;
forward only;
forwarders {
192.168.0.50; # ns1.subdomainA.domain.com
192.168.0.51;# ns2.subdomainA.domain.com
};
};
Chad Philip Johnson
On 11/15/22 05:33, Petr Špaček wrote:
On 15. 11. 22 9:47, Chad Philip Johnson via bind-users wrote:
Greetings all,
I've been chasing my tail over a strange configuration issue and was
hoping somebody could point me in the right direction.
I have two forwarders defined in my main 'options' section, but when
'forward first' is enabled all lookups go to the root servers as if
forwarding is completely disabled. This behavior is also the same for
name lookups that exist in locally defined zones.
When I change the configuration to 'forward only', lookup requests
are forwarded and resolved properly, but of course lookup through the
root servers is no longer available.
Four systems are exhibiting this issue: two running Rocky Linux 8
with BIND 9.11.26-RedHat-9.11.26-6.el8 (Extended Support Version)
<id:3ff8620>, and two running Rocky Linux 9 with BIND 9.16.23-RH
(Extended Support Version) <id:fde3b1f>.
My configuration is pretty straightforward and I'm someone who
(mostly) knows what he's doing. That said, I might be missing
something obvious, or looking at an important detail a bit
cross-eyed. I have spent some time searching through various BIND
resources and bug reports. I also combed through a few dozen old
messages on this mailing list.
If I'm being too brief on configuration details then I can share any
and all relevant information, I just didn't want to dump potentially
extraneous information into this message.
It would be much easier to debug with configuration file :-)
Please include at least options {} and zone {} configuration for one
of the zones which is giving you trouble.
If your config has overlapping subtrees then please include all zone
{} definitions from top down.
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users