Я использую 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