Inconsistent Behavior with 'forward first'

Petr Špaček pspacek at isc.org
Wed Nov 16 10:08:58 UTC 2022


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.



More information about the bind-users mailing list