Вопросы Теги

Проверка передачи подчиненной зоны от главного приводит к соединению отказано

Я использую bind9 с webmin, чтобы попытаться настроить вторичный DNS для нашего основной сервер имен. Я нахожусь в очень простой ситуации, но я не могу заставить мастер передать зоны подчиненному.

Я сконфигурировал мастер так, чтобы подчиненный был в индексе сервера Webmin, а затем настроил это как подчиненное устройство под подчиненными серверами кластера, затем сконфигурировано allow_transfer на главном устройстве с IP-адресом подчиненного устройства. iptables -nL показывает порты 53 и 953 как открытые как на главном, так и на подчиненном устройстве. netstat -lnpt показывает с именем прослушивание 53 (на главном и подчиненном), но когда я запускаю тестовую передачу записей на подчиненное устройство, я получаю: 

Testing transfer of slave zone from 10.191.0.2 .. .. from 10.191.0.2 : 
Failed : ;; Connection to 10.191.0.2#53(10.191.0.2) for 
test.example.com failed: connection refused.

Конфигурации для зоны на главном устройстве. 2 

zone "test.example.com" {
  type master;
  file "/var/lib/bind/test.example.com.hosts";
  notify yes;
  allow-transfer {
    10.191.0.3;
    };
};

Конфигурации зоны на ведомом .3 

zone "test.example.com" {
  type slave;
  masters {
    10.191.0.2;
    };
  file "/var/lib/bind/test.example.com.hosts";
  allow-transfer {
    10.191.0.2;
    };
  allow-update {
    10.191.0.2;
    };
};

Я знаю, что что-то упускаю, но не могу понять.

Спасибо за любую помощь

1
задан 15 June 2019 в 00:19
1 ответ

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

Система DNS по определению используется по умолчанию Протокол UDP на порте 53. Но эта служба предназначена для предотвращения фрагментации ответа, поэтому, как только ответ станет большим, он «откатится» обратно к протоколу TCP.

С UDP (в принципе) вы не можете гарантировать, что ответ будет получен полностью и что некоторая его часть не будет потеряна во время доставки после того, как TCP отправит подтверждение. В результате, когда ответ становится достаточно маленьким, чтобы соответствовать одному элементу, используется UDP. Как только ответ будет больше, чтобы быть в безопасности, система отправит его как TCP, чтобы не заботиться о фрагментации и порядке доставки. Примером более широкого ответа может быть «обычный» ответ с связующими записями (где запрашивать следующий шаг итерации запроса - курица и яйцо ;-) или материал DNSSEC) или только что упомянутая передача зоны.

Как rfc5936 - DNS Zone Transfer Протокол (AXFR) заявляет:

Поскольку точность важна, TCP или другой надежный протокол должен использоваться для запросов AXFR .

...

С добавлением EDNS0 и приложений для которых требуется много небольших зон, например, в веб-хостинге и некоторых сценариях ENUM, сеансы AXFR на UDP теперь кажутся желательными. Однако есть некоторые аспекты сеансов AXFR, которые нелегко преобразовать в UDP.

Таким образом, этот документ не обновляет RFC 1035 в этом отношении: Сеансы AXFR через транспорт UDP не определены .

Итак, исходя из цитаты, вы видите, что протокол TCP для передачи зоны является обязательным.

В общем (не только из-за передачи зоны) вам следует разрешите TCP / 53 и UDP / 53 на DNS-сервере правильно работать. Разрешение только UDP / 53 обеспечит только частичную работоспособность.

- изменить (Чт, 20 июня, 10:20 UTC, 2019) -

добавление фактического ответа на вопрос (AXFR использует TCP) - спасибо Håkan Линдквист

3
ответ дан 3 December 2019 в 18:23

Теги

Похожие вопросы