Конфигурация DNS для доменов леса

У меня есть автономная настройка лесного домена для тестирования. Верхний уровень — DOMAIN.TEST, в котором есть 2 контроллера домена в качестве DNS-серверов. У этих контроллеров домена включено 3 сетевых интерфейса. 1 для домена верхнего уровня и 2 для дочерних доменов, которые находятся в отдельных диапазонах IP. Это связано с тем, что эти 2 дочерних домена будут разъединены на некоторое время, а затем снова подключены. Таким образом, они будут использовать свой локальный DNS для обработки DNS-запросов, и при подключении смогут получить доступ к контроллерам домена верхнего уровня. Таким образом, клиенты только из диапазонов IP дочерних доменов могут получить доступ к общим ресурсам контроллеров верхнего уровня. Сетевые интерфейсы этих контроллеров верхнего уровня следующие:

DC01
------
NIC1: 192.168.1.1  -> DNS 192.168.1.2,192.168.1.1 (Верхний домен)
NIC2: 192.170.5.21 -> DNS 192.170.5.1,192.170.5.2 (Дочерний домен 1)
NIC3: 192.171.5.21 -> DNS 192.171.5.1,192.171.5.2 (Дочерний домен 2)

DC02
-------
NIC1: 192.168.1.2  -> DNS 192.168.1.2,192.168.1.1 (Верхний домен)
NIC2: 192.170.5.22 -> DNS 192.170.5.1,192.170.5.2 (Дочерний домен 1)
NIC3: 192.171.5.22 -> DNS 192.171.5.1,192.171.5.2 (Дочерний домен 2)

Дочерние домены содержат контроллеры домена каждый и находятся в диапазонах верхнего уровня для связи с ИБП и другим управляемым оборудованием, а также в своих доменных диапазонах как DNS дочерних доменов.

CHILD1-DC01
-------
NIC1: 192.168.1.11 -> DNS 192.168.1.1,192.168.1.2 (Верхний домен)
NIC2: 192.170.5.1  -> DNS 192.170.5.2,192.170.1.1 (Дочерний домен 1)

CHILD1-DC02
-------
NIC1: 192.168.1.12 -> DNS 192.168.1.1,192.168.1.2 (Верхний домен)
NIC2: 192.170.5.2  -> DNS 192.170.5.1,192.170.1.2 (Дочерний домен 1)

CHILD2-DC01
-------
NIC1: 192.168.1.13 -> DNS 192.168.1.1,192.168.1.2 (Верхний домен)
NIC2: 192.171.5.1  -> DNS 192.171.5.2,192.171.1.1 (Дочерний домен 2)

CHILD2-DC02
-------
NIC1: 192.168.1.14 -> DNS 192.168.1.1,192.168.1.2 (Верхний домен)
NIC2: 192.171.5.2  -> DNS 192.171.5.1,192.171.1.2 (Дочерний домен 2)

Здесь мы немного запутались. Перенаправители на контроллерах верхнего уровня указывают на все контроллеры домена на домене верхнего уровня:

192.168.1.1
192.168.1.1
192.168.1.11
192.168.1.12
192.168.1.13
192.168.1.14

Когда дочерний домен отключен, один контроллер остается подключенным, а другой уходит вместе с остальной системой. Когда он отключен, это вызывает задержку для всех записей DNS. Поэтому вот вопросы.

1. Почему перенаправители DNS не должны указывать на диапазоны дочернего домена? Потому что, когда они это делают, они не решают или не обрабатывают правильные DNS-запросы?
2. Разве перенаправители, указывающие на записи дочернего домена, не должны перенаправлять эти запросы на DNS-ы дочернего домена для обслуживания этих запросов?
3. Когда отключено, есть ли способ исправить проблему с неудачами или длительными неудачами при поиске DNS?

Вы смешиваете некоторые вещи, которые делают ваш проект более сложным, чем это необходимо для управления. Похоже, вы используете сетевые интерфейсы и перенаправители для воссоздания базовой функциональности маршрутизации/DNS/Active Directory, что можно сделать с помощью базовой конфигурации без этой сложности.

Вы можете удалить все NIC2 и NIC3 из DC01, и DC02. Вы можете убрать NIC1 на CHILD1-DC01, CHILD1-DC02, CHILD2-DC01 и CHILD2-DC02. Базовая маршрутизация IP позволит всем им общаться со всеми устройствами во всех подсетях, используя только один сетевой интерфейс. Это следует принимать как задачу маршрутизации/фаервола. Использование нескольких сетевых интерфейсов необходимо только в том случае, если между этими подсетями нет маршрутизации, что маловероятно, поскольку все подсети доступны для DC01 и DC02. Ваш маршрутизатор должен передавать трафик между всеми адресами NIC1 и другими устройствами, не требуя дополнительных сетевых интерфейсов на других подсетях.

DC01 NIC1: 192.168.1.1. DNS записи 192.168.1.1, 192.168.1.2
DC02 NIC1: 192.168.1.2. DNS записи 192.168.1.2, 192.168.1.1
CHILD1-DC01 NIC1: 192.170.5.1. DNS записи 192.170.5.2, 192.170.5.1
CHILD1-DC02 NIC1: 192.170.5.2. DNS записи 192.170.5.1, 192.170.5.2
CHILD2-DC01 NIC1: 192.171.5.1. DNS записи 192.171.5.2, 192.171.5.1
CHILD2-DC02 NIC1: 192.171.5.2. DNS записи 192.171.5.1, 192.171.5.2

Вы можете удалить все свои перенаправители, так как они используются неправильно. Их следует перенастроить так, чтобы перенаправители указывали на следующий вышестоящий DNS. Как правило, это ваше устройство сетевой безопасности, обеспечивающее DNS, внешний DNS, специфичный для вашего сайта интернет-провайдер, Google и т.д. или их сочетание (интернет-провайдер, затем Google). Это не должен быть другой DNS-сервер AD, за исключением особых обстоятельств. Перенаправители используются для того, чтобы избежать использования корневых подсказок, поскольку лучшей практикой считается использование других доступных вам DNS-сервисов, а не отправка трафика на глобальные корневые серверы.

Когда вы настраиваете лес, он всавит записи NS и A “glue”, которые правильно настроят ваш DNS. Итак, DOMAIN.TEST будут иметь записи для CHILD1.DOMAIN.TEST, указывающие на 192.170.5.1 и 192.170.5.2; и записи для CHILD2.DOMAIN.TEST, указывающие на 192.171.5.1 и 192.171.5.2. Эти записи предоставляют всю необходимую информацию. Также конфигурируется, чтобы ребенок нашел верхний домен.

*Примечание: Перенаправители и условные перенаправители являются отдельными темами. Перенаправители предназначены для всех других доменов, не известных DNS-серверу (в общем случае интернет или следующий вышеупомянутый сервер в организации). Условные перенаправители предназначены для определенных известных доменов, которые не размещены на текущем сервере. Условные перенаправители для родительского домена или для отдельного леса допустимы.

На этом этапе, когда подключено, все клиенты и контроллеры домена должны иметь возможность находить друг друга и выполнять все функции AD, используя простую маршрутизацию через ваш маршрутизатор. Используя перенаправители, они должны иметь возможность разрешать DNS-интернет-запросы, если вы хотите этого. Если настроен другой перенаправитель DNS, отличный от AD, они должны иметь возможность разрешать все другие имена, доступные от этого DNS. Они должны иметь возможность общаться со всеми вашими другими IP-устройствами во всех 3 подсетях (при условии, что ваш маршрутизатор/фаервол позволяет это).

Для ситуации, когда дочерние домены будут отключены на время, есть несколько хороших вариантов. Ваша основная проблема, похоже, заключается в тайм-ауте попытки поиска DNS-записей на недоступном сервере. Один простой вариант для этого сценария — использовать сам Active Directory для обработки этого. Контроллеры домена должны использовать зоны DNS, интегрированные в Active Directory. Один из вариантов в этих зонах позволяет им реплицироваться либо по всему домену, либо по всему лесу. Если вы измените зоны для репликации через весь лес, то все контроллеры домена всегда будут иметь локальную копию зоны и будут авторитетно отвечать на любой запрос как для верхнего, так и для дочернего доменов.

Таким образом, клиенты общаются только со своими локальными серверами AD для DNS. Если запрос относится к любому верхнему или дочернему домену, локальная DNS, интегрированная в AD, ответит как обычно, не требуя какой-либо коммуникации с DNS-серверами на других сайтах. Если запрос на имя интернет, перенаправитель использует локальный DNS интернет-провайдера или другой перенаправитель по вашему выбору. DNS клиентов дочерних доменов никогда не нужно напрямую запрашивать серверы DC01 или DC02, так как CHILDx-DC0x имеют реплики всех тех же данных.

Когда подключенные клиенты и серверы в дочерних подсетях смогут общаться с устройствами в верхней подсети. Когда отключенные, они будут терпеть неудачи по причинам тайм-аута IP (хост недоступен), а не из-за причин DNS. Производительность DNS улучшится, так как устройства дочерних доменов не придется ждать тайм-аута DNS-запроса к серверу DC01 или DC02.

*Примечание: Существует множество ограничений для Active Directory, когда она работает в отключенном режиме, где контроллеры домена не могут видеть друг друга. Отключение должно быть кратким (недели). Если сети отключены слишком долго, репликация AD в конечном счете потерпит неудачу. Это, как правило, происходит на периоде времени, называемом “время жизни объекта”, который по умолчанию составляет 90 дней, однако существуют и другие более изменчивые лимиты, которые могут повлиять на это раньше. Для получения дополнительной информации изучите роли “Операции единого главного сервера”, особенно роль “Эмулятор PDC” и “Мастер RID”, и общие проблемы репликации AD для отключенных контроллеров домена, такие как “время жизни объекта” и остающийся объект.

Также я не уверен, является ли DOMAIN.TEST замещающим вашу домен, или ваш домен буквально “DOMAIN.TEST”. Лучшая практика для AD (несмотря на большое количество контента, который поощряет обратное) — использовать поддомен вашего зарегистрированного интернет-домена. Многие примеры, включая Microsoft, предлагают использовать domain.local, domain.dns или другие вымышленные имена. Эти примеры следует игнорировать, и следует использовать поддомен правильно зарегистрированного и поддерживаемого интернет-домена. Например: ad.example.com; corporate.example.com; global.example.com и т.д.

Многогоменные контроллеры домена являются обычно плохой практикой. Особенно в ситуациях, когда один из интерфейсов недоступен для всех остальных клиентов. Контроллеры домена (без большого вмешательства) будут регистрировать все интерфейсы в DNS, включая записи SRV на всех интерфейсах. Клиенты могут попытаться подключиться к одному или нескольким интерфейсам, которые недоступны для них, что может вызвать задержки или отказы подключения. Вы можете ознакомиться с этой статьей от Microsoft о шагах, необходимых для решения нежелательного поведения: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-communication-fails

Честно говоря, я не понимаю вопросов 1 и 2. Я думаю, что существует фундаментальное недопонимание базовых DNS-концептов или, по крайней мере, как работают перенаправление и делегирование в Windows DNS, из-за чего я не понимаю задаваемый вопрос. Иначе говоря, я думаю, что вопросы почти запрашивают точную причину или объяснение, почему что-то нарушено, когда оно неправильно настроено.

Что касается вопроса 3. Да, вы можете достичь этого с помощью anycast. Пока вы используете unicast IP-адреса для DNS-серверов, клиент dns в Windows всегда будет следовать известной процедуре (https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-client-resolution-timeouts). Чтобы избежать проблемы, вы можете настроить адрес anycast, которым будут совместно использоваться ваши DNS-серверы, который будет сразу доступен и отзывчив независимо от того, уйдет ли один сервер в автономный режим.

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

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

Я думаю, что вам нужно сделать в родительском/корневом домене – это настроить делегирования для детей соответствующим дочерним контроллерам домена. Затем на каждом дочернем контроллере домена настроить условные перенаправители дляzones родителей и сиблингов.

Вот учебник по делегированию зоны: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/reviewing-dns-concepts#delegation

Вот пошаговое руководство по настройке условного перенаправителя для зоны: https://woshub.com/dns-conditional-forwarding-policy-windows-server/