Inconsistent Behavior with 'forward first'
Chad Philip Johnson
chad at anacronist.com
Tue Nov 15 18:16:40 UTC 2022
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.
__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.
>
More information about the bind-users
mailing list