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

Bind: «неожиданный конец ввода» из-за NS

Я наткнулся на странную ошибку в конфигурации 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 - это слишком низкий уровень функциональности, чтобы сработать.

Надеюсь, мой анализ в какой-то степени неверен. Я думаю, что у вас очень интересная проблема, и я хотел бы, чтобы кто-нибудь дал на нее лучший ответ, потому что я тоже хотел бы извлечь из нее урок.