где разместить интегрированный DNS-сервер Active Directory и какой тип использовать

где разместить интегрированный DNS-сервер Active Directory и какой тип использовать

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

один из филиалов очень маленький (5 пользователей) и имеет очень медленное сетевое подключение. Нужен ли мне DNS-сервер и, если да, какой тип зоны он должен размещать?

Второй филиал намного больше (около 30 пользователей) и имеет лучшее сетевое подключение. Нужен ли этому офису DNS-сервер, и если да, то какой тип зоны вы бы порекомендовали?

решение1

Интегрированные зоны Active Directory должны размещаться на контроллерах домена (DC), и все интегрированные зоны Active Directory являются основными зонами. Учитывая это, мы на самом деле говорим о том, где размещать контроллеры домена, обслуживающие дополнительную роль DNS-сервера.

Определение места размещения DC/DNS-серверов не всегда простое. Однако, как правило, я придерживаюсь мнения, что любое расположение филиала, которое будет использовать службы Active Directory (аутентификация, файловые службы и т. д.), выигрывает от наличия локального DC и интегрированных в домен DNS-сервисов.

Возможно, вы уже многое из этого знаете, так что наберитесь терпения…

Принимая решение о размещении DC/DNS-серверов, помните о следующем:

  • Члены домена в значительной степени полагаются на службы DNS для поиска ресурсов домена. Например, когда компьютер, присоединенный к домену, загружается, он запрашивает записи локатора служб домена (SRV) в DNS, чтобы найти контроллер домена, с которым нужно выполнить аутентификацию. Без локального экземпляра DNS этот процесс должен происходить по потенциально медленной ссылке сайта. Конечно, как только компьютер найдет контроллер домена, он продолжит аутентификацию с этим сервером, пока что-то не заставит клиента найти другой DC.

  • По медленному соединению регулярные действия по аутентификации на удаленных DC, запросы к ресурсам домена и выполнение других стандартных DNS-запросов могут создать вялый и несколько утомительный пользовательский опыт. Локальный DC/DNS-сервер может значительно улучшить пользовательский опыт (я полностью за пользовательский опыт), устраняя задержки.

  • Если связь между сайтами отключается и отсутствует локальная служба DNS, ваши пользователи не смогут просматривать Интернет, если вы не настроили вторичные серверы DNS. Проблема, с которой я столкнулся со вторичными серверами DNS, заключается в том, что каждый запрос сначала пытается связаться с первичным сервером DNS, прежде чем обратиться к вторичному серверу DNS. Это действительно портит пользовательский опыт.

Для небольшого филиала с 5 пользователями и медленным соединением вы, возможно, сможете обойтись без локального DC/DNS-сервера, если:

  • Пользователи не зависят от возможности аутентификации в домене (если удаленный контроллер домена недоступен для обслуживания запросов на аутентификацию, пользователи все равно должны иметь возможность входить в свои локальные системы, используя кэшированные учетные данные).

  • Недоменные DNS-серверы доступны для обслуживания запросов в случае, если ссылка на ваш сайт выйдет из строя. Некоторые маршрутизаторы с поддержкой DNS могут выборочно пересылать запросы для выбранных доменов на определенные DNS-серверы. Например, обычные DNS-запросы могут пересылаться на общедоступные DNS-серверы (например, DNS-серверы, предоставленные вашим интернет-провайдером), в то время как запросы к mydomain.local могут пересылаться по защищенной ссылке на ваш внутренний DNS-сервер. Этот метод устраняет задержку переключения с основного на вторичный DNS-сервер для каждого клиента.

Тем не менее, я думаю, что вам все равно будет лучше с локальным DC/DNS-сервером, даже если у вас всего 5 пользователей. Вы рассматривалиКонтроллеры домена только для чтения?

Для вашего крупного филиала я бы определенно рекомендовал предоставить сайту локальный DC/DNS-сервер.

Связанный контент