1

Доменное имя моей организации - 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; };
   };
};
|источник

0