Материал: Книга Active directory

f 454 Интеграция DNS с AD DS Глава 9

I К СВЕДЕНИЮ Зоны GlobalNames

' Более подробную информацию о зонах GNZ можно найти в документе «DNS Glo-

Системы DNS и WINS

Если в сети требуется использовать много имен из одной метки и вы не можете обеспечить их поддержку с помощью GNZ из-за слишком большого их количества, установите службу WINS хотя бы на двух серверах в сети. Служба WINS автоматически генерирует и управляет именами всех объектов в сети. Помните, что служба WINS является компонентом Windows Server 2008, а не ролью, и представляет устаревшую технологию, которая не обновлялась с момента выхода Windows Server 2003.

Далее раскроем нюансы, о которых нельзя забывать при развертывании WINS.

•Служба WINS не отображается в Диспетчере сервера (Server Manager). Для ее администрирования нужно использовать консоль W I N S в программной группе Администрирование (Administrative Tools).

•Служба WINS поддерживает лишь 1Ру4-адреса и не обновляется для поддержки IPv6.

•Чтобы обеспечить отказоустойчивость для имен из одной метки, в сети нужно разместить хотя бы два WINS-сервера. Эти два сервера следует конфигурировать для использования синхронизации обеих баз данных имен.

•Необходимо убедиться, что значения для W I N S указаны в параметрах DHCP, пересылаемых на компьютеры, которые требуют использовать динамические 1Ру4-адреса. Следует указать два параметра: первый перечисляет серверы имен, а второй идентифицирует тип узла, с которым будет работать каждый клиент.

о Параметр 044 WINS/NBNS-серверы (044 W I N S / N B N S Servers) указывает серверы со службой WINS.

• Параметр 046 Тип узла W I N S / N B T (046 W I N S / N B T Node Туре) определяет, как узлы взаимодействуют с WINS . Чаще всего используется тип узла 0x8 или тип узла Смешанный (Hybrid). Этот тип сводит к минимуму широковещание, необходимое в сетях с именами из одной метки.

• Вы также можете интегрировать W I N S и DNS, модифицировав свойства зоны прямого просмотра (FLZ). Это окно свойств содержит вкладку WINS, которая не используется, если в сети нет WINS-серверов (рис. 9-16). Данный компонент удобно использовать в сетях, где многие клиенты полагаются на службу WINS, причем имена некоторых клиентских устройств не представлены в DNS. Однако участниками динамической инфраструктуры DNS могут являться все операционные системы Windows начиная с Windows 2000. Сети с клиентами ниже Windows 2000 попадаются все реже.

Можно использовать V/IW5 для разрешения »т-«ен. не найми»»» ло запросу к пространству DNS. )VtNS лоддерхмвэет rontxo 1Ру4-адоесв

р" Иоадльаонатьпрлмейпрогмдтр WINS

Г" He выполнять репликации этой записи IP-aapec

DNS и DHCP

При работе с динамической системой DNS и интеграции службы DNS в хра- , нилище AD DS необходимо менять традиционные методы, используемые администраторами сети для настройки параметров DHCP каждого клиентского

устройства с применением динамических адресов IPv4 или IPv6.

По традиции сетевые администраторы указывают в параметрах DHCP сервера лишь два центральных DNS-сервера. Эти серверы обеспечивают все клиентские устройства адресами DNS, необходимыми для разрешения внешних и внутренних имен FQDN, поскольку в силу централизованной локализации серверов любому клиенту в удаленном узле придется выполнять просмотр DNS через соединение WAN.

^ Однако в случае интеграции DNS в хранилище каталогов данные DNS становятся доступными на контроллерах домена, поэтому для предоставления служб проверки подлинности клиентов независимо от их расположения контроллеры домена распределяются в сети. Некоторые организации содержат контроллеры доменов, которые доступны в любой точке, где есть хотя бы 20 клиентов. С возможностями виртуализации серверов Hyper-V и с появлением контроллеров RODC теперь можно создавать сети, где преобладают контроллеры доменов. Это означает, что данные DNS только для чтения будут доступны в каждом удаленном узле или филиале. Для поиска FQDN-имен клиенты могут Использовать серверы в своем локальном узле.

Но для выполнения локального поиска клиенты должны знать о наличии локальных DNS-серверов. Рассмотрим следующий сценарий.

• Клиент в удаленном узле использует динамический IP-адрес, выделяемый через DHCP.

•В удаленном узле есть два контроллера домена.

•Структура DNS интегрирована в каталог и реплицируется вместе с разделом домена.

•Служба DHCP передает значения только двух DNS-серверов в центральном узле.

•Когда клиент загружает утром свою машину, он выполняет поиск DNS для локализации и входа на ближайший контроллер домена.

•Для запроса разрешения имен от одного из двух центральных контроллеров доменов через соединение WAN выполняется поиск DNS.

•Центральные DNS-серверы просматривают узел клиента и определяют, что

внем есть два локальных контроллера домена для поддержки входа.

•DNS-сервер возвращает клиенту местоположение ближайшего контроллера домена, опять-таки через соединение WAN.

•Клиент связывается со своим локальным контроллером домена для входа

всеть.

Если в этом сценарии отсутствует подключение WAN, клиент не может войти в сеть, даже несмотря на то, что данные DNS хранятся локально на двух контроллерах домена.

По этой причине параметры D H C P нужно модифицировать следующим образом.

•Для обеспечения избыточности область видимости сервера должна включать хотя бы два адреса центральных DNS-серверов. В случае отказа локальных контроллеров домена клиенты смогут войти в сеть, но только через подключение WAN.

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

мости D H C P добавляется значение 006 DNS-серверы (006 DNS Servers). м На всех контроллерах домена также должна быть установлена роль DNSсервер (DNS Server). Если зона DNS содержится в хранилище каталогов AD DS, она будет доступна для службы DNS сразу после установки роли DNS-сервера на контроллер домена. Больше ничего не нужно конфигури-

ровать, за исключением глобальных параметров DNS.

Используйте приведенные инструкции при планировании интеграции DNS с DHCP.

Разделы каталога приложений

В определенных ситуациях для поддержки репликации данных DNS может потребоваться создать настраиваемые разделы каталога приложений. Помните, что разделы каталога приложений контролируют область репликации содержащихся в них данных. Сервер DNS, при его установке вместе с AD DS, создает в лесу два раздела каталога приложений: один для данных леса и один в каждом домене для данных домена, однако в определенных обстоятельствах эти две области могут не соответствовать ситуации, особенно в комплексных лесах-

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

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

По умолчанию разрешение имен между двумя дочерними доменами выполняется через корневой домен леса. Разработчики ежедневно получают доступ к этому домену, поэтому с целыо ускорения разрешения имен вы создали настраиваемый раздел каталога приложений для совместного использования записей DNS производственным доменом и доменом разработчиков. Это означает, что, поскольку эти данные доступны в разделе, производственным DNS-серверам не потребуется разрешать имена домена разработчиков через корневой домен леса, как показано на рис. 9-17.

| Корневой домен леса ]

Разработчик получает доступ к домену разработок из глобального дочернего производственного домена для ускорения процесса разрешения имен DNS

Рис. 9-17. Использование настраиваемых разделов каталога приложений для совместного использования данных DNS двумя дочерними доменами

16 Зак. 3399