Не удается выполнить прямое разрешение через вторичный сервер имен в делегированную зону

Доменное имя моей организации - example.com . Серверы имен организации называются ns1.example.com и ns2.example.com .

Я являюсь администратором поддомена project.example.com . Наше пространство IP-адресов - 10.0.0.0/22 ​​(10.0.0.0 - 10.0.3.255) .

У меня есть один основной сервер имен и один дополнительный сервер имен ( ns1.project.example.com (10.0.0.2) и ns2.project.example.com (10.0.1.2), соответственно).

Этими серверами имен является Bind 9.10.3, работающий под Debian 9.5.

Я настроил эти зоны (для которых я либо уполномочен, либо делегирую полномочия:

• 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

Серверы имен моей организации направляют (не делегируют) запросы в пространство имен project.example.com моим серверам имен.

Для запросов имен, для которых я не являюсь уполномоченным, не делегирую, не пересылаю и не кэширую, я использую режим «Только пересылка» для пересылки запроса на ns1.example.com / ns2.example.com .

Я разделил часть своего пространства имен на поддомен sub.project.example.com . Пространство IP-адресов для этого субдомена 10.0.3.0/24 .

Существует только один сервер имен для sub.project.example.com . Его имя хоста - ns1.sub.project.example.com (10.0.3.2) .

Этот сервер имен - Bind 9.9.4, работающий под CentOS 7.3.

Для прямого поиска в sub.project.example.com я делегирую ns1.sub.project.example.com (10.0.3.2) . У меня есть требуемая клейкая запись на месте.

Для обратных поисков в 3.0.10.in-addr.arpa я пересылаю (не делегирую) на ns1.sub.project.example.com (10.0.3.2) . Я не могу делегировать, так как я не контролирую 0.10.in-addr.arpa .

Эта проблема

Есть один конкретный случай, когда вещи не работают. Этот случай возникает, когда я выключаю свой основной сервер имен, чтобы проверить дополнительный сервер имен.

Предположим, я открываю командную строку на своем настольном компьютере с Windows - my-host.example.com . Я не могу запросить host-1.sub.project.example.com . Время ожидания запроса истекло.

Когда я запускаю tcpdump на дополнительном сервере имен ns2.project.example.com (10.0.1.2), я вижу запрос, поступающий с ns1.example.com . Однако вместо того, чтобы делегировать его ns1.sub.project.example.com, он пересылает его обратно на ns1.example.com .

Чтобы перефразировать первый абзац этого раздела, запрос выполняется успешно, если работает мой основной сервер имен ns1.project.example.com (10.0.0.2) . Если основной сервер имен не работает, а дополнительный сервер имен ns2.project.example.com (10.0.1.2) получает запрос, это случай сбоя.

Я включил мои файлы конфигурации ниже.

Как я могу решить эту проблему?

Конфигурация зоны (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 Первичная конфигурация сервера имен

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 Конфигурация вторичного сервера имен

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; }; }; };