Я наткнулся на странную ошибку в конфигурации Bind ведущий-ведомый.
Зона отлично работает на мастере, но на подчиненных я получаю такие ошибки:
21-May-2014 19:06:07.573 general: info: zone example.com/IN: refresh: failure trying master 1.2.3.4#53 (source 0.0.0.0#0): unexpected end of input
Вот как выглядит мой файл привязки:
@ IN SOA ns1.example.com. admin.example.com. (
2014052116 ; Serial
28800 ; Refresh
180 ; Retry
604800 ; Expire
21600 ) ; Minimum
86400 IN A 1.2.3.4
86400 IN MX 10 mail.example.com.
86400 IN MX 20 mail2.example.com.
86400 IN NS ns1.example.com.
86400 IN NS ns2.example.com.
86400 IN NS ns3.example.com.
86400 IN NS ns1.example.net.
86400 IN NS ns2.example.net.
86400 IN NS ns3.example.net.
86400 IN NS ns1.example.org.
; until here it works -- if I uncomment the below here, I'll get "end of input" failures.
; 86400 IN NS ns2.example.org.
; 86400 IN NS ns3.example.org.
* 86400 IN A 1.2.3.4
[...]
Если я раскомментирую две закомментированные строки NS - я получу ошибку «Конец ввода». Если я буду их комментировать, все будет нормально.
Есть ли максимальное количество NS или размер файла, которое вызывает сбой?
Спасибо.
Редактировать:
named-checkzone:
master # named-checkzone example.com example.com.
zone example.com/IN: example.com/MX 'mail.example.com' is a CNAME (illegal)
zone example.com/IN: example.com/MX 'mail2.example.com' is a CNAME (illegal)
zone example.com/IN: loaded serial 2014052105
OK
глобальные параметры:
options {
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
listen-on { any; };
dnssec-enable yes;
recursion no;
statistics-file "/var/log/named.stats";
try-tcp-refresh yes;
};
Версия (одинаковая на всех трех серверах):
# named -v
BIND 9.8.4-rpz2+rl005.12-P1
Я думаю, вы столкнулись с максимально допустимым размером пакета UDP DNS в 512 байт. До того, как сделать ожидаемый AXFR
запрос (который работает в режиме TCP; без ограничений по размеру), подчиненный сервер также сделает SOA
запрос, чтобы подтвердить, что мастер считает себя полномочным для зоны.
Проблема, с которой вы столкнулись, заключается в том, что SOA
ответ будет содержать не только разделы ВОПРОС и ОТВЕТ:
A
и AAAA
записи для этих серверов имен. Вот почему корректировка вашего NS
записи или связанные с ними A
/AAAA
records влияет на успешность передачи всей зоны, но добавление других типов записей не влияет. Ваши комбинированные авторитетные данные слишком велики для передачи по UDP.
К сожалению, я не знаю никаких обходных путей для этого. Справочное руководство администратора BIND действительно ссылается на try-tcp-refresh
вариант, но по умолчанию это да, и он не отключен в ваших параметрах. Я не уверен, что перенос зоны - это конец ваших проблем. Даже в случае успеха это вызовет проблемы для любых клиентов, которые, в свою очередь, будут делать любой запрос, который будет включать ваши разделы AUTHORITY и ADDITIONAL. EDNS0 предназначен для решения подобных проблем, но я считать Раздувание AUTHORITY - это слишком низкий уровень функциональности, чтобы сработать.
Надеюсь, мой анализ в какой-то степени неверен. Я думаю, что у вас очень интересная проблема, и я хотел бы, чтобы кто-нибудь дал на нее лучший ответ, потому что я тоже хотел бы извлечь из нее урок.