Вопрос: 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 или размер файла, который приводит к его сбою?

Благодарю.

Редактировать:

именованных 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

5
2018-05-21 17:14


Источник




Ответы:


Я думаю, что вы столкнулись с максимально допустимым размером пакета UDP DNS размером 512 байт. До принятия ожидаемого AXFR запрос (который работает в режиме TCP, без ограничения размера), подчиненный сервер также SOA чтобы подтвердить, что хозяин считает себя авторитетным для зоны.

Проблема, с которой вы столкнулись, заключается в том, что SOA ответ будет содержать больше, чем просто разделы ВОПРОС и ОТВЕТ:

  • Раздел AUTHORITY будет содержать все настроенные серверы имен.
  • ДОПОЛНИТЕЛЬНЫЙ раздел будет содержать все известные A а также AAAA записи для этих серверов имен.

Вот почему NS записей или связанных с ними A/AAAA записи влияют на успех всей передачи зоны, но добавление других типов записей не влияет. Данные с объединенными полномочиями слишком велики для того, что может передаваться через UDP.

К сожалению, я не знаю никаких обходных путей для этого. Справочное руководство администратора BIND делает ссылку на try-tcp-refresh , но по умолчанию это да, и он не отключен в ваших настройках. Я не уверен, что передача зоны - это конец ваших проблем. Даже если это произойдет, это вызовет проблемы для любых клиентов, которые, в свою очередь, сделают любой запрос, который будет включать ваши разделы AUTHORITY и ADDITIONAL. EDNS0 предназначен для решения таких проблем, но я думать НАРУШЕНИЕ АВТОРИТЕТА слишком функционально низкое для того, чтобы он мог ударить.

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


4
2018-05-21 21:45