Назад | Перейти на главную страницу

Тестирование передачи ведомой зоны от ведущего приводит к отказу в соединении

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

Я настроил ведущее устройство так, чтобы подчиненное устройство было в индексе сервера Webmin, затем настроило его как подчиненное устройство в кластерных подчиненных серверах, а затем настроило allow_transfer на мастере с ip ведомого. iptables -nL показывает, что порты 53 и 953 открыты как на главном, так и на подчиненном устройстве. netstat -lnpt показывает named прослушивание 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;
    };
};

Конфиги для зоны на slave .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;
    };
};

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

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

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

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

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

Как rfc5936 - Протокол передачи зоны DNS (AXFR) заявляет:

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

...

С добавлением 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 Lindqvist