Can't Perform Forward Resolution via Secondary Nameserver to Delegated Zone

Question

My organization's domain name is example.com. The organization's nameservers are named ns1.example.com and ns2.example.com.

I am the administrator for subdomain project.example.com. Our IP address space is 10.0.0.0/22 (10.0.0.0 - 10.0.3.255).

I have one primary nameserver and one secondary nameserver (ns1.project.example.com (10.0.0.2) and ns2.project.example.com (10.0.1.2), respectively).

These nameservers are Bind 9.10.3 running under Debian 9.5.

I have configured these zones (for which I am either authoritative or I delegate authority:

• project.example.com
• 0.0.10.in-addr.arpa
• 1.0.10.in-addr.arpa
• 2.0.10.in-addr.arpa
• 3.0.10.in-addr.arpa

My organization's nameservers forward (not delegate) queries within the project.example.com namespace to my nameservers.

For queries of names I am not authoritative for, do not delegate, do not forward, and do not have cached, I use "Forward Only" mode to forward the query to ns1.example.com / ns2.example.com.

I have split out a portion of my namespace into sub-domain sub.project.example.com. The IP address space for this sub-domain is 10.0.3.0/24.

There is only one nameserver for sub.project.example.com. Its hostname is ns1.sub.project.example.com (10.0.3.2).

This nameserver is Bind 9.9.4 running under CentOS 7.3.

For forward lookups within sub.project.example.com, I delegate to ns1.sub.project.example.com (10.0.3.2). I do have the required glue record in place.

For reverse lookups within 3.0.10.in-addr.arpa, I forward (not delegate) to ns1.sub.project.example.com (10.0.3.2). I cannot delegate since I do not control 0.10.in-addr.arpa.

The Problem

There's one particular case where things are not working. This case occurs when I shut down my primary nameserver to test the secondary nameserver.

Suppose I open a command prompt on my Windows desktop machine, which is my-host.example.com. I cannot query for host-1.sub.project.example.com. The request times out.

When I run tcpdump on the secondary nameserver ns2.project.example.com (10.0.1.2), I see the query coming in from ns1.example.com. However, rather than delegating it to ns1.sub.project.example.com, it forwards it back to ns1.example.com.

To re-phrase the opening paragraph of this section, the query succeeds if my primary nameserver ns1.project.example.com (10.0.0.2) is running. If the primary nameserver is down and the secondary nameserver ns2.project.example.com (10.0.1.2) gets queried, that's the failure case.

I've included my configuration files below.

How may I solve this problem?

Zone Configuration (NS Records)

; project.example.com

@   NS   ns1
@   NS   ns2

sub   NS   ns1.sub

; Forward 3.0.10.in-addr.arpa rather than delegate it
; We can't delegate since we don't own 0.10.in-addr.arpa.
; That's why the line below is commented out.
; 203.240.10.in-addr.arpa.   NS   centos-s1.ipa

; Glue record
ns1.sub   A   10.0.3.2

project.example.com Primary Nameserver Configuration

controls {};

acl "internal-hosts" { 10.0.0/22; 127/8; };
acl "external-hosts" { 10/8; 192.168/16; 172.16/12; };

view "internal-view" {
   match-clients { "internal-hosts"; };

   zone "project.example.com" {
      type master;
      file "db.project.example.com_internalView";
      forwarders { };
   };

   zone "0.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.0";
      forwarders { };
   };

   zone "1.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.1";
      forwarders { };
   };

   zone "2.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.2";
      forwarders { };
   };

   zone "3.0.10.in-addr.arpa" {
      type forward;
      forwarders { 10.0.3.2; };
   };

   // Internal-only zone
   zone "31.172.in-addr.arpa" {
      type master;
      file "db.172.31";
      forwarders { };
   };
};

view "external-view" {
   match-clients { "external-hosts"; };

   zone "project.example.com" {
      type master;
      file "db.project.example.com_externalView";
      forwarders { };
   };

   zone "0.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.0";
      forwarders { };
   };

   zone "1.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.1";
      forwarders { };
   };

   zone "2.0.10.in-addr.arpa" {
      type master;
      file "db.10.0.2";
      forwarders { };
   };

   zone "3.0.10.in-addr.arpa" {
      type forward;
      forwarders { 10.0.3.2; };
   };
};

project.example.com Secondary Nameserver Configuration

controls {};

acl "internal-hosts" { 10.0.0/22; 127/8; };
acl "external-hosts" { 10/8; 192.168/16; 172.16/12; };

masters "my-master" { 10.0.0.2; };

view "internal-view" {
   match-clients { "internal-hosts"; };

   zone "project.example.com" {
      type slave;
      file "bak.project.example.com_internalView";
      masters { my-master; };
      forwarders { };
   };

   zone "0.0.10.in-addr.arpa" {
      type slave;
      file "bak.10.0.0";
      masters { my-master; };
      forwarders { };
   };

   zone "1.0.10.in-addr.arpa" {
      type slave;
      file "bak.10.0.1";
      masters { my-master; };
      forwarders { };
   };

   zone "2.0.10.in-addr.arpa" {
      type slave;
      file "bak.10.0.2";
      masters { my-master; };
      forwarders { };
   };

   zone "3.0.10.in-addr.arpa" {
      type forward;
      forwarders { 10.0.3.2; };
   };

   // Internal-only zone
   zone "31.172.in-addr.arpa" {
      type slave;
      file "bak.172.31";
      masters { my-master; };
      forwarders { };
   };
};

view "external-view" {
   match-clients { "external-hosts"; };

   zone "project.example.com" {
      in-view "internal-view";
   };

   zone "0.0.10.in-addr.arpa" {
      in-view "internal-view";
   };

   zone "1.0.10.in-addr.arpa" {
      in-view "internal-view";
   };

   zone "2.0.10.in-addr.arpa" {
      in-view "internal-view";
   };

   zone "3.0.10.in-addr.arpa" {
      // in-view "internal-view";
      type forward;
      forwarders { 10.0.3.2; };
   };
};