BIND9: У экспедиторов есть какой-нибудь приоритет?

Я просто настраиваю свой BIND9-сервер, и пока он работает хорошо. Я решил интегрировать небольшой трюк в возможности моего DNS. Я хочу разрешить IANA-совместимые домены, такие как * .com и * .net, DNS-сервером моего интернет-провайдера, но я также хочу интегрировать OpenNIC-домены, такие как .geek и .project, используя OpenNIC-DNS-сервер в качестве форвардера. Так что мой раздел пересылки в основном выглядит так:

forwarders {
   IP.OF.ISP.DNS;
   IP.OF.OPENNIC.DNS;
}

Несмотря на то, что OpenNIC-DNS способны разрешать IANA-домены, я не хочу им доверять, потому что захватить важные домены, такие как paypal.com или ebay.com, слишком просто. Bind9 запрашивает записи пересылок шаг за шагом (от первого ip до последнего ip) или произвольно? Я хочу убедиться, что DNS моего провайдера имеет высший приоритет при разрешении доменов.

Есть ли способ, которым я могу "отладить" DNS-запрос непосредственно на моем DNS-сервере, чтобы увидеть, какой сервер используется для поиска запрошенного домена?

Я искал это раньше, но у меня проблемы с поиском чего-то лучшего, чем это сейчас: https://lists.isc.org/pipermail/bind-users/2012-April/087455.html

BIND8 и далее считают, что каждый из форвардеров начинается с «равного веса». Основываясь на SRTT ответов, сервер имен начинает отдавать предпочтение одному над другим. Определенный процент запросов всегда будет попадать в тот, который имеет более высокую задержку, чтобы повторно протестировать данные и сохранить справедливый расчет веса. (учитывая, что после того, как запись кэширована, с экспедиторами больше не будут обращаться за ней, пока не истечет TTL)

Короче говоря, директива пересылки разработана с учетом избыточности и минимальной задержки, а не в модели аварийного переключения с активным резервированием . Это не будет делать то, что вы хотите, и я не знаю каких-либо директив BIND для перенастройки этого поведения. В конце концов, я пристально смотрю на документацию BIND в своей работе, поэтому я чувствую себя довольно уверенно в этом утверждении.