Re: Inconsistent Behavior with 'forward first'

2022-11-15 Thread Chad Philip Johnson via bind-users 
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:

O

Re: How to *require* TSIG for NOTIFY

2022-11-15 Thread Jesus Cea 

On 15/11/22 5:40, Ondřej Surý wrote:

It’s `also-notify ;` and `notify explicit;`

The online documentation is here: 
https://bind9.readthedocs.io/en/v9_16_34/reference.html 



That configuration affects to the primary, I don't see how it affects 
the slaves.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Re: Inconsistent Behavior with 'forward first'

2022-11-15 Thread Petr Špaček 

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) 
, and two running Rocky Linux 9 with BIND 9.16.23-RH 
(Extended Support Version) .


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.


--
Petr Špaček
Internet Systems Consortium
--
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

Inconsistent Behavior with 'forward first'

2022-11-15 Thread Chad Philip Johnson via bind-users 

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) 
, and two running Rocky Linux 9 with BIND 9.16.23-RH 
(Extended Support Version) .


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.


Best,

--
Chad Philip Johnson
--
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