Рекурсия BIND9 на подчиненных серверах для делегированной зоны - не работает

Я просматривал документацию BIND / DNS и не смог найти четкого ответа. tl; dr - запрос вторичного сервера имен для делегированной зоны Запись делает не работа с включенной рецизией. И, по определению, не работает и с отключенной рекурсией, поскольку все, что определено в зоне, с нашей точки зрения, - это NS и связующая запись.

Программный стек: bind-9.3.6-4 на CentOS 5.4 x86 для вторичного сервера имен; bind-9.2.4-30 на Centos 4.7 x86 для основного сервера имен.

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

Наша установка выглядит следующим образом (имена / IP-адреса изменены для защиты невиновных):

ns.pr.example.com == первичный сервер имен, 10.10.0.1, 192.168.0.1

ns1.pr.example.com == вторичный сервер имен, 10.11.0.1, 192.168.0.2

ns2.pr.example.com == вторичный сервер имен, 10.11.0.2, 192.168.0.3

delegated.pr.example.com == делегированная подзона

nsdelegated.pr.example.com == авторский NS для

поддомен delegated.pr.example.com, 10.11.0.5 НЕ под нашим контролем!

Вы заметите, что ns1 и ns2 могут общаться с ns.pr.example.com через общую сеть - 192.168.0.0/24. Однако ns.pr.example.com не может поговорите с хостом nsdelegated.pr.example.com, у которого есть только адрес 10.11.0.0/24.

Сеть 192.168 заменяет наше пространство общедоступных IP-адресов; но сети 10.10 и 10.11 являются частными закрытыми сетями, используемыми для кластерных вычислений. О подключении ns.pr.example.com к сети 10.11 напрямую или через статический маршрут не может быть и речи.

На первичном сервере имен, ns.pr.example.com, в файл зоны добавляется следующее определение вместе с обновленным серийным номером:

/etc/ named.conf:

zone "pr.example.com" { type master; file [db.filename]; };

db.filename:

delegated.pr.example.com. IN NS nsdelegated.pr.example.com. nsdelegated.pr.example.com. IN A 10.11.0.5 ; glue record

Это реплицируется на подчиненные серверы, ns1 и ns2. Запись можно увидеть как в плоских файлах, так и подтвердить с помощью dig:

пример раба

dig -t ns +short @ns1 delegated.pr.example.com nsdelegated.pr.example.com IN A 10.11.0.5

мастер-пример

dig -t ns +short @ns delegated.pr.example.com nsdelegated.pr.example.com IN A 10.11.0.5

Сам nsdelegated сервер реагирует:

dig -t a +short @nsdelegated.pr.example.com randomhost.delegated.pr.example.com 10.11.0.222

Но поиск на вторичном сервере имен с установленным битом, требуемым для рекурсии (по умолчанию), не выполняется.

dig +recurse +short -t a @ns1 randomhost.delegated.pr.example.com [no output]

Он также не работает на первичном сервере, ns, но этого можно было ожидать, поскольку ns.pr.example.com не может связаться с 10.11.0.5 и ответить на запрос. Нерекурсивные запросы также терпят неудачу, поскольку соответствующая информация должна быть получена с сервера nsdelegated.pr.example.com.

Мой вопрос: почему рекурсивные вопросы к вторичный серверы имен выходят из строя? У них есть правильная информация о делегировании, запись NS и связующая запись, и они могут связываться с делегированным сервером имен.

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

Есть идеи или предложения по отладке? Я включил максимальное ведение журнала для named, а также ведение журнала запросов, но мне не удалось получить достоверную информацию. Не было очевидного журнала «покажи мне поисковые запросы, которые вы делаете от имени клиентов».

Спасибо.